remove prototypes with no matching function

Implement support for framebuffers that don't start on a page boundary.
This happens on the new 14" and 16" Macbook Pro where we deliberately use
a framebuffer that skips the first few lines to avoid "the notch".
The offset of the first pixel is added to struct wsdisplay_fbinfo. The
stride is added as well, mirroring the value returned by the
WSDISPLAYIO_LINEBYTES ioctl, such that we can retire that one in the
future. A compat ioctl is implemented to help the transition. The compat
code will be removed after OpenBSD 7.3 has been released.

ok miod@

Constify struct cfattach.

ok visa@ a long time ago

spelling

change wsdisplay attribute type from long to uint32_t

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@

Use C99 named initializers for struct wsdisplay_accessops fields.
No functional change.

Enable jfb-style acceleration on XVR-600.

Use getpropstringA(), not getpropstring(), to get the card's name. This ensures
its value has not been clobbered when ifb_accel_identify() is invoked, and
restores textmode acceleration on Expert3D{,-Lite} and XVR-1200.
Broken since 1.17, sigh

opration -> operation

Change the wsdisplay_emulops return types from void to int; emulops will now
return zero on success and nonzero on failure.
This commit only performs mechanical changes for the existing emulops to
always return zero.

Stricter checks when deciding which acceleration code to use. Instead of
matching on pci id, and if no match is found, on pci subsystem id, match
on openfirmware device names (which amounts to a pci id AND subsystem id
exact match).

This makes XVR-500 cards (``bobcat'') run without acceleration. Which is
better than trying to use ``jfb'' acceleration and fail.

ok kettenis@

Extend the acceleration code to handle jfb (XVR-600, XVR-1200) models, the
software only code is kept in case we can't reliably figure out what kind
of device we are facing.

Tested on XVR-1200 by Mattieu Baptiste, and on Expert3D-Lite by me.

The acceleration code would not work on XVR-600 and XVR-1200, so if it turns
out it doesn't work, fall back to dumb software routines until we know better.

Also, do not attach to the second head of the XVR-1200 yet, the second
node lacks basic frame buffer properties.

Tested by Mattieu Baptiste, thanks!

Allow registers to be mapped in WSDISPLAYIO_MODE_MAPPED mode, if
machdep.allowaperture > 0. To be used by the xserver shortly.

Accelerated routines for solid fills and inverted cursor.

Allow both overlay areas to be mmap()ed by userland in WSDISPLAYIO_MODE_MAPPED
mode.

Give ifb its own display type (be sure to make includes before rebuilding
wsconsctl)

Move ifb identification to its own routine. We can not simply have the ifb
probe win over vgafb, since one may configure a kernel with vgafb but without
ifb (especially slackers who forget to rerun config).

Low-hanging fruit: while the blitter is still an untamed beast, implement
eraserows as one low-style line of solid fills, and then as many copyrect
calls as necessary to fill the complete area.

Use acceleated operations for copycols, too.

Make blitter ``go the other way'' when scrolling down.

It turns out that parasites are caused by (some) pixel writes with the
high bit set; restrict ourselves to 7bpp operation. This brings back
text-mode color support.

joint work with kettenis@

Use hardware acceleration for scrolling and make sure we only use the low bit
of each pixel value. This avoids "overlay artifacts" and turns ifb(4) into
a usable console framebuffer.

help from miod@

Sync the sparc64 fb* api with the recent changes done on sparc.

Make sure we pick the right PCI BARs on Expert3D cards (which have an extra
BAR that we need to skip).

ok miod@

typo; deraadt

Not-functional-enough driver for the Sun Expert3D cards, put in tree as an
incentive for further tinkering only; not for the faint of heart.

Implement support for framebuffers that don't start on a page boundary.
This happens on the new 14" and 16" Macbook Pro where we deliberately use
a framebuffer that skips the first few lines to avoid "the notch".
The offset of the first pixel is added to struct wsdisplay_fbinfo. The
stride is added as well, mirroring the value returned by the
WSDISPLAYIO_LINEBYTES ioctl, such that we can retire that one in the
future. A compat ioctl is implemented to help the transition. The compat
code will be removed after OpenBSD 7.3 has been released.

ok miod@

Constify struct cfattach.

ok visa@ a long time ago

spelling

change wsdisplay attribute type from long to uint32_t

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@

Use C99 named initializers for struct wsdisplay_accessops fields.
No functional change.

Enable jfb-style acceleration on XVR-600.

Use getpropstringA(), not getpropstring(), to get the card's name. This ensures
its value has not been clobbered when ifb_accel_identify() is invoked, and
restores textmode acceleration on Expert3D{,-Lite} and XVR-1200.
Broken since 1.17, sigh

opration -> operation

Change the wsdisplay_emulops return types from void to int; emulops will now
return zero on success and nonzero on failure.
This commit only performs mechanical changes for the existing emulops to
always return zero.

Stricter checks when deciding which acceleration code to use. Instead of
matching on pci id, and if no match is found, on pci subsystem id, match
on openfirmware device names (which amounts to a pci id AND subsystem id
exact match).

This makes XVR-500 cards (``bobcat'') run without acceleration. Which is
better than trying to use ``jfb'' acceleration and fail.

ok kettenis@

Extend the acceleration code to handle jfb (XVR-600, XVR-1200) models, the
software only code is kept in case we can't reliably figure out what kind
of device we are facing.

Tested on XVR-1200 by Mattieu Baptiste, and on Expert3D-Lite by me.

The acceleration code would not work on XVR-600 and XVR-1200, so if it turns
out it doesn't work, fall back to dumb software routines until we know better.

Also, do not attach to the second head of the XVR-1200 yet, the second
node lacks basic frame buffer properties.

Tested by Mattieu Baptiste, thanks!

Allow registers to be mapped in WSDISPLAYIO_MODE_MAPPED mode, if
machdep.allowaperture > 0. To be used by the xserver shortly.

Accelerated routines for solid fills and inverted cursor.

Allow both overlay areas to be mmap()ed by userland in WSDISPLAYIO_MODE_MAPPED
mode.

Give ifb its own display type (be sure to make includes before rebuilding
wsconsctl)

Move ifb identification to its own routine. We can not simply have the ifb
probe win over vgafb, since one may configure a kernel with vgafb but without
ifb (especially slackers who forget to rerun config).

Low-hanging fruit: while the blitter is still an untamed beast, implement
eraserows as one low-style line of solid fills, and then as many copyrect
calls as necessary to fill the complete area.

Use acceleated operations for copycols, too.

Make blitter ``go the other way'' when scrolling down.

It turns out that parasites are caused by (some) pixel writes with the
high bit set; restrict ourselves to 7bpp operation. This brings back
text-mode color support.

joint work with kettenis@

Use hardware acceleration for scrolling and make sure we only use the low bit
of each pixel value. This avoids "overlay artifacts" and turns ifb(4) into
a usable console framebuffer.

help from miod@

Sync the sparc64 fb* api with the recent changes done on sparc.

Make sure we pick the right PCI BARs on Expert3D cards (which have an extra
BAR that we need to skip).

ok miod@

typo; deraadt

Not-functional-enough driver for the Sun Expert3D cards, put in tree as an
incentive for further tinkering only; not for the faint of heart.

Constify struct cfattach.

ok visa@ a long time ago

spelling

change wsdisplay attribute type from long to uint32_t

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@

Use C99 named initializers for struct wsdisplay_accessops fields.
No functional change.

Enable jfb-style acceleration on XVR-600.

Use getpropstringA(), not getpropstring(), to get the card's name. This ensures
its value has not been clobbered when ifb_accel_identify() is invoked, and
restores textmode acceleration on Expert3D{,-Lite} and XVR-1200.
Broken since 1.17, sigh

opration -> operation

Change the wsdisplay_emulops return types from void to int; emulops will now
return zero on success and nonzero on failure.
This commit only performs mechanical changes for the existing emulops to
always return zero.

Stricter checks when deciding which acceleration code to use. Instead of
matching on pci id, and if no match is found, on pci subsystem id, match
on openfirmware device names (which amounts to a pci id AND subsystem id
exact match).

This makes XVR-500 cards (``bobcat'') run without acceleration. Which is
better than trying to use ``jfb'' acceleration and fail.

ok kettenis@

Extend the acceleration code to handle jfb (XVR-600, XVR-1200) models, the
software only code is kept in case we can't reliably figure out what kind
of device we are facing.

Tested on XVR-1200 by Mattieu Baptiste, and on Expert3D-Lite by me.

The acceleration code would not work on XVR-600 and XVR-1200, so if it turns
out it doesn't work, fall back to dumb software routines until we know better.

Also, do not attach to the second head of the XVR-1200 yet, the second
node lacks basic frame buffer properties.

Tested by Mattieu Baptiste, thanks!

Allow registers to be mapped in WSDISPLAYIO_MODE_MAPPED mode, if
machdep.allowaperture > 0. To be used by the xserver shortly.

Accelerated routines for solid fills and inverted cursor.

Allow both overlay areas to be mmap()ed by userland in WSDISPLAYIO_MODE_MAPPED
mode.

Give ifb its own display type (be sure to make includes before rebuilding
wsconsctl)

Move ifb identification to its own routine. We can not simply have the ifb
probe win over vgafb, since one may configure a kernel with vgafb but without
ifb (especially slackers who forget to rerun config).

Low-hanging fruit: while the blitter is still an untamed beast, implement
eraserows as one low-style line of solid fills, and then as many copyrect
calls as necessary to fill the complete area.

Use acceleated operations for copycols, too.

Make blitter ``go the other way'' when scrolling down.

It turns out that parasites are caused by (some) pixel writes with the
high bit set; restrict ourselves to 7bpp operation. This brings back
text-mode color support.

joint work with kettenis@

Use hardware acceleration for scrolling and make sure we only use the low bit
of each pixel value. This avoids "overlay artifacts" and turns ifb(4) into
a usable console framebuffer.

help from miod@

Sync the sparc64 fb* api with the recent changes done on sparc.

Make sure we pick the right PCI BARs on Expert3D cards (which have an extra
BAR that we need to skip).

ok miod@

typo; deraadt

Not-functional-enough driver for the Sun Expert3D cards, put in tree as an
incentive for further tinkering only; not for the faint of heart.

spelling

change wsdisplay attribute type from long to uint32_t

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@

Use C99 named initializers for struct wsdisplay_accessops fields.
No functional change.

Enable jfb-style acceleration on XVR-600.

Use getpropstringA(), not getpropstring(), to get the card's name. This ensures
its value has not been clobbered when ifb_accel_identify() is invoked, and
restores textmode acceleration on Expert3D{,-Lite} and XVR-1200.
Broken since 1.17, sigh

opration -> operation

Change the wsdisplay_emulops return types from void to int; emulops will now
return zero on success and nonzero on failure.
This commit only performs mechanical changes for the existing emulops to
always return zero.

Stricter checks when deciding which acceleration code to use. Instead of
matching on pci id, and if no match is found, on pci subsystem id, match
on openfirmware device names (which amounts to a pci id AND subsystem id
exact match).

This makes XVR-500 cards (``bobcat'') run without acceleration. Which is
better than trying to use ``jfb'' acceleration and fail.

ok kettenis@

Extend the acceleration code to handle jfb (XVR-600, XVR-1200) models, the
software only code is kept in case we can't reliably figure out what kind
of device we are facing.

Tested on XVR-1200 by Mattieu Baptiste, and on Expert3D-Lite by me.

The acceleration code would not work on XVR-600 and XVR-1200, so if it turns
out it doesn't work, fall back to dumb software routines until we know better.

Also, do not attach to the second head of the XVR-1200 yet, the second
node lacks basic frame buffer properties.

Tested by Mattieu Baptiste, thanks!

Allow registers to be mapped in WSDISPLAYIO_MODE_MAPPED mode, if
machdep.allowaperture > 0. To be used by the xserver shortly.

Accelerated routines for solid fills and inverted cursor.

Allow both overlay areas to be mmap()ed by userland in WSDISPLAYIO_MODE_MAPPED
mode.

Give ifb its own display type (be sure to make includes before rebuilding
wsconsctl)

Move ifb identification to its own routine. We can not simply have the ifb
probe win over vgafb, since one may configure a kernel with vgafb but without
ifb (especially slackers who forget to rerun config).

Low-hanging fruit: while the blitter is still an untamed beast, implement
eraserows as one low-style line of solid fills, and then as many copyrect
calls as necessary to fill the complete area.

Use acceleated operations for copycols, too.

Make blitter ``go the other way'' when scrolling down.

It turns out that parasites are caused by (some) pixel writes with the
high bit set; restrict ourselves to 7bpp operation. This brings back
text-mode color support.

joint work with kettenis@

Use hardware acceleration for scrolling and make sure we only use the low bit
of each pixel value. This avoids "overlay artifacts" and turns ifb(4) into
a usable console framebuffer.

help from miod@

Sync the sparc64 fb* api with the recent changes done on sparc.

Make sure we pick the right PCI BARs on Expert3D cards (which have an extra
BAR that we need to skip).

ok miod@

typo; deraadt

Not-functional-enough driver for the Sun Expert3D cards, put in tree as an
incentive for further tinkering only; not for the faint of heart.

change wsdisplay attribute type from long to uint32_t

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@

Use C99 named initializers for struct wsdisplay_accessops fields.
No functional change.

Enable jfb-style acceleration on XVR-600.

Use getpropstringA(), not getpropstring(), to get the card's name. This ensures
its value has not been clobbered when ifb_accel_identify() is invoked, and
restores textmode acceleration on Expert3D{,-Lite} and XVR-1200.
Broken since 1.17, sigh

opration -> operation

Change the wsdisplay_emulops return types from void to int; emulops will now
return zero on success and nonzero on failure.
This commit only performs mechanical changes for the existing emulops to
always return zero.

Stricter checks when deciding which acceleration code to use. Instead of
matching on pci id, and if no match is found, on pci subsystem id, match
on openfirmware device names (which amounts to a pci id AND subsystem id
exact match).

This makes XVR-500 cards (``bobcat'') run without acceleration. Which is
better than trying to use ``jfb'' acceleration and fail.

ok kettenis@

Extend the acceleration code to handle jfb (XVR-600, XVR-1200) models, the
software only code is kept in case we can't reliably figure out what kind
of device we are facing.

Tested on XVR-1200 by Mattieu Baptiste, and on Expert3D-Lite by me.

The acceleration code would not work on XVR-600 and XVR-1200, so if it turns
out it doesn't work, fall back to dumb software routines until we know better.

Also, do not attach to the second head of the XVR-1200 yet, the second
node lacks basic frame buffer properties.

Tested by Mattieu Baptiste, thanks!

Allow registers to be mapped in WSDISPLAYIO_MODE_MAPPED mode, if
machdep.allowaperture > 0. To be used by the xserver shortly.

Accelerated routines for solid fills and inverted cursor.

Allow both overlay areas to be mmap()ed by userland in WSDISPLAYIO_MODE_MAPPED
mode.

Give ifb its own display type (be sure to make includes before rebuilding
wsconsctl)

Move ifb identification to its own routine. We can not simply have the ifb
probe win over vgafb, since one may configure a kernel with vgafb but without
ifb (especially slackers who forget to rerun config).

Low-hanging fruit: while the blitter is still an untamed beast, implement
eraserows as one low-style line of solid fills, and then as many copyrect
calls as necessary to fill the complete area.

Use acceleated operations for copycols, too.

Make blitter ``go the other way'' when scrolling down.

It turns out that parasites are caused by (some) pixel writes with the
high bit set; restrict ourselves to 7bpp operation. This brings back
text-mode color support.

joint work with kettenis@

Use hardware acceleration for scrolling and make sure we only use the low bit
of each pixel value. This avoids "overlay artifacts" and turns ifb(4) into
a usable console framebuffer.

help from miod@

Sync the sparc64 fb* api with the recent changes done on sparc.

Make sure we pick the right PCI BARs on Expert3D cards (which have an extra
BAR that we need to skip).

ok miod@

typo; deraadt

Not-functional-enough driver for the Sun Expert3D cards, put in tree as an
incentive for further tinkering only; not for the faint of heart.

Use C99 named initializers for struct wsdisplay_accessops fields.
No functional change.

Enable jfb-style acceleration on XVR-600.

Use getpropstringA(), not getpropstring(), to get the card's name. This ensures
its value has not been clobbered when ifb_accel_identify() is invoked, and
restores textmode acceleration on Expert3D{,-Lite} and XVR-1200.
Broken since 1.17, sigh

opration -> operation

Change the wsdisplay_emulops return types from void to int; emulops will now
return zero on success and nonzero on failure.
This commit only performs mechanical changes for the existing emulops to
always return zero.

Stricter checks when deciding which acceleration code to use. Instead of
matching on pci id, and if no match is found, on pci subsystem id, match
on openfirmware device names (which amounts to a pci id AND subsystem id
exact match).

This makes XVR-500 cards (``bobcat'') run without acceleration. Which is
better than trying to use ``jfb'' acceleration and fail.

ok kettenis@

Extend the acceleration code to handle jfb (XVR-600, XVR-1200) models, the
software only code is kept in case we can't reliably figure out what kind
of device we are facing.

Tested on XVR-1200 by Mattieu Baptiste, and on Expert3D-Lite by me.

The acceleration code would not work on XVR-600 and XVR-1200, so if it turns
out it doesn't work, fall back to dumb software routines until we know better.

Also, do not attach to the second head of the XVR-1200 yet, the second
node lacks basic frame buffer properties.

Tested by Mattieu Baptiste, thanks!

Allow registers to be mapped in WSDISPLAYIO_MODE_MAPPED mode, if
machdep.allowaperture > 0. To be used by the xserver shortly.

Accelerated routines for solid fills and inverted cursor.

Allow both overlay areas to be mmap()ed by userland in WSDISPLAYIO_MODE_MAPPED
mode.

Give ifb its own display type (be sure to make includes before rebuilding
wsconsctl)

Move ifb identification to its own routine. We can not simply have the ifb
probe win over vgafb, since one may configure a kernel with vgafb but without
ifb (especially slackers who forget to rerun config).

Low-hanging fruit: while the blitter is still an untamed beast, implement
eraserows as one low-style line of solid fills, and then as many copyrect
calls as necessary to fill the complete area.

Use acceleated operations for copycols, too.

Make blitter ``go the other way'' when scrolling down.

It turns out that parasites are caused by (some) pixel writes with the
high bit set; restrict ourselves to 7bpp operation. This brings back
text-mode color support.

joint work with kettenis@

Use hardware acceleration for scrolling and make sure we only use the low bit
of each pixel value. This avoids "overlay artifacts" and turns ifb(4) into
a usable console framebuffer.

help from miod@

Sync the sparc64 fb* api with the recent changes done on sparc.

Make sure we pick the right PCI BARs on Expert3D cards (which have an extra
BAR that we need to skip).

ok miod@

typo; deraadt

Not-functional-enough driver for the Sun Expert3D cards, put in tree as an
incentive for further tinkering only; not for the faint of heart.