gfb_draw if 'flip' is specified. This causes the mouse cut region
to be displayed in reverse color so it is visbile.
- Use the "other" implementation of gfb_cursor for the creator driver,
which doesn't assume there is a hardware cursor. It seems that the
hardware cursor that creator provides doesn't display the character
under the cursor in reverse colors, so the driver does this manually
and uses the hardware cursor for the mouse pointer (which it also works
much better for). This is wedged here because it required less hoops
than accessing the syscons vtb from inside the video driver, which is
needed to read the character and color attributes under the new cursor
position.
These are fixed resolution and operate only in pixel mode so they present
a challenge to syscons (square peg, round hole, etc, etc). The driver
provides a video driver interface for syscons and a separate character
device for X to mmap. Wherever possible the creator's accelarated graphics
functions are used so text mode is very fast.
Based roughly on the openbsd driver.
round the result up to a multiple of 4 bytes so that it will always
be a multiple of the sample size. Also use the actual buffer size
from sc->bufsz instead of the default DS1_BUFFSIZE.
This fixes panics and bad distortion I have seen on Yamaha DS-1
hardware, mainly when playing certain Real Audio media.
Reviewed by: orion (an earlier version of the patch)
first sample in the buffer to be ignored. The bug caused a repetitive
glitch in one of the stereo channels when playing mono sound on
configurations that use the monotostereo16 feeder.
Reviewed by: orion
to intptr_t. This fixes a compiler warning (integer from pointer
without cast) in scvgarndr.c when SC_PIXEL_MODE is defined.
o Define readb() and writeb(). Both are used in scvgarndr.c when,
guess what, SC_PIXEL_MODE is defined.
Both changes are ia64 specific.
Found by: LINT
CB710, CB720, CB1211, CB1225, CB1410 and CB1420
These are likely licensed designed from TI, and the Linux PCMCIA code
treats them as TI chips.
Add comment, but no ID for the 711E1 from O2Micro.
vendors that list the vendor ID in the proper byte order. The second
section is for vendors that get it backwards. The third is for what
appear to be 'random' ones (although 0xcxxx appears to be coherent
enough that maybe somebody else is assigning those numbers).
