support 16bit colour
This requires kernel support, which was committed yesterday.

don't enable xrender support unless we have 24bit colour

be more consistent with debug options

fix previous - still include xf86Cursor.h

merge xf86-video-suncg14 1.1.3, xf86-video-suncg6 1.1.3,
xf86-video-sunffb 1.2.3, xf86-video-sunleo 1.2.3,
and xf86-video-suntcx 1.1.3.

ffb_driver.c probably needs explicit testing that the EXA/XAA
code still works properly.

initial import of xf86-video-suncg14-1.1.3

more xf86RamDac.h vs xf86Cursor.h.

fix tpyo
thanks rin@

treat PictOpOver with a solid source and an empty mask as simple fill
somewhat less glitchiness in gtk3 but we're not quite there yet

disable accidentally committed debug goop

make debug output a bit more manageable

don't pretend to support PictOpSrc - those can be quite a bit more complicated
than simple copy ops
With this gtk3 buttons are still occasionally glitchy but at least we don't
crash anymore

consistently use SX_RENDER_DEBUG, hide some more debug goop

fix calculation for start of off-screen memory in 24bit colour

add some comments

make ALU instructions use the same format as load/store instructions
same binary generated

add macros to simplify issuing SX instructions, hide the address alignment /
displacement shenanigans SX needs, and make the code more resemble the
inline assembler source it arguably is

always drain the pipeline before writing SX_ROP_CONTROL

break down large, unaligned copies into chunks that CG14Copy8_short_*()
can handle, make sure destinations are aligned whenever possible
now we only fall back to byte-wise access for really small copies, which
we probably shouldn't bother throwing at SX in the first place

skip reading destination fb if we're going to overwrite it, only read words
we need to partially write
while there write mask registers only if we're actually going to need them
another 20% speedup

CG14Copy8_short_rop(): skip the funnel shifter if source and destination are
aligned. Small but measurable speedup.

add another Copy8() variant:
- supports unaligned source and destination
- uses all 32bit accesses
- supports copies up to 124 pixels wide so an entire line fits into registers
and we can ignore x direction
... mostly an exercise in learning how to use the funnel shifter
TODO:
- skip the funnel shifter if source and destination are aligned
- skip fb reads where possible, like straight GXcopy

Pixel == unsigned long, fix format.

shutup debug goop

start optimizing Copy8() operations
- only go right to left if srcY == dstY in the same pixmap
- special case copy where src and dst X have the same alignment
- special case the above where we don't need to read dst
scrolling should now be about as fast as SX can go

use 32bit accesses for non-trivial cases in Solid8() as well
while there make GXset and GXclear special cases of GXcopy
with this we only ever read the destination pixmap if we really need to

draw very narrow rectangles correctly

fix shadow fb geometry calculations
... not that a shadow fb helps much on this hardware.

first step towards acceleration in 8 bit colour
- Copy() uses byte mode
- Solid() uses 32bit writes where possible for plain fills
... mostly works, but could be quite a bit faster

support 8 bit colour
no acceleration yet, the code is riddled with 32bit per pixel assumptions

remove old guesswork code to determine VRAM size - we can rely on OBP now

avoid stalling the CPU by letting the SX instruction FIFO drain every couple
of memory instructions.
No more missed IPIs when building stuff in an xterm so far...

poll SX_BZ instead of SX_MT, also complain and dump register info if CG14Wait()
times out.

mostly fix amd64 xorg-server 1.20 builds:

- avoid bswap_16 etc defines for now. ends up with code-in-decl
- more ABI_VERSION 23 fixes (BlockHandler/WakeHandler) including re-fix
from previous
- more Notify API
- more shadowUpdatePackedWeak() removal
- remove fd_set handling from intel driver (part of ABI_VERSION 23)
- cope better with PixMap/Drawable separation in new server
- remove support for maxHValue and maxVValue (XXX?)
- hide drmmode_udev_notify() when not building udev
- comment out nouveau 'wfb' support, xorg-server 1.20 only supplies
either 'wfb' or 'fb' interface, not both, and we choose 'fb'
- define 'pointer' in nv_proto.h rather than relying upon Xdefs.h
- normalise the value of _XTYPEDEF_POINTER
- EGL is broken (missing) in xsrc currently

do up to 4 pixels at a time CG14Comp_Over*()

RGB/BGR-flip source images in CG14Comp_Over32*() with non-solid sources
as well. This takes care of most remaining RGB/BGR issues in xrender.
Next step: do more than one pixel at a time in those operations.

support PictOpAdd with A8 source and ARGB/ABGR destination
now labels in windowmaker look right again

handle 8bit pixmaps in CG14PrepareCopy(), now the glyph cache works properly

CG14CheckComposite():
- don't crash with SX_DEBUG set
- check destination format

Don't directly use assignments in if (), but add the commonly accepted
explicit pair of parenthesis.

There is no X_DEBUG

do PictOpOver operations 4 pixels at a time - this is a vector processor,
let's do some vector processing
-> about 40% speed increase

- DPRINTF() some debug output
- remove unused #defines

adapt to xorg 1.18

XFree86LOADER is officially no longer optional ( and we didn't treat it as
optional for quite some time ) so start nuking it

mibstore.h and its miInitializeBackingStore() have been otherwise empty
since at least xorg-server 1.10. remove all reference to them as the
header is gone in xorg-server 1.18.

write all SX commands to 64bit-aligned addresses
now this works on rev. 27 hardware

now we get PictOpOver with no source alpha and a 32bit mask right
( mostly gtk2 icons and button images )
TODO: RGB vs. BGR

support PictOpOver with 32bit source and mask

"support" PictOpOver with 32bit source and 32bit mask
this needs more work but at least it makes things like gkrellm readable

- fetch fill colour for text drawing in CheckComposite, swap red and blue
channels as needed
- support solid sources without a drawable
now gtk2 apps no longer crash the Xserver and text is drawn in the correct
colour
next step: 32bit PictOpOver with 32bit mask, gtk2 seems to use those a lot

support PictOpOver with 32bit source without alpha, alpha in mask
now KDE3 looks mostly right
( yes, it's almost usable on a 125MHz HyperSPARC )
gtk2 apps still crash though

missed one
( move CG14Comp_Over32Solid() too )

- support PictOpSrc, mask is ignored so far
- support PictOpOver with non-solid source, with or without mask - now QT3
icons are rendered properly
- move render operations into their own file

support hardware acceleration via SX
This requires a recent cgfourteen kernel driver which allows userland to map
SX register space.
Basic acceleration is enabled by default ( use Option "Accel" "false" to turn
it off ), XRender support is incomplete but good enough for anti-aliased text
rendering ( enable with Option "xrender" "true" ).

remove some unnecessary #includes

merge xf86-video-suncg14 1.1.2, xf86-video-suncg6 1.1.2,
xf86-video-sunffb 1.2.2, xf86-video-suntcx 1.1.2 and xf86-video-sunleo 1.2.1

XXX: these might need more help

initial import of xf86-video-suncg14-1.1.2

#include <sys/ioctl.h>

oops, missed some debug spam

add shadowfb and hardware cursor support

use ioctl(FBIOSVIDEO) in CG14SaveScreen(), now the Xserver can actually turn
the monitor off
TODO: hw cursor

merge xf86-video-suncg14 1.1.1

initial import of xf86-video-suncg14-1.1.1

Make ioctl(CG14_SET_PIXELMODE) a proper NetBSD ioctl() ( as in use _IOW ),
also fix some bogosity in colour weights and depth.
With this and the kernel changes committed earlier the cg14 in my SS20 works
with the suncg14 driver.
TODO:
- beat some sanity in the order in which the Xserver issues various ioctl()s
and opens or closes devices to reduce unnecessary flicker and make sure we
end up in the right colour mode when entering and exiting X
- add hw cursor support
- support 8 bit visuals along with 24 bit or alone for high resolutions

xf86Version.h is no more

suncg14 driver, from Xorg