Re: rasops1 bug?

> When making out that list of monochrome devices, I didn't expect
> many people to either own them or have the ancient monitor compatible
> with some of them

Oh, noone does.

As for the monitors, I myself use a good old Goldstar^WLG ``Flatron'' 17
inches CRT (probably older than 10 years by now), with a large set of
adaptor cables. Most of the older frame buffers can output to 3 or 5 BNC
connectors, and I am the lucky owner of a passive and complete (i.e. can
be used in both directions) VGA HD15 to 5 BNC cable (from an IBM
XStation X terminal), which I use a lot.

For Macintoshes, you can still find DE15 to VGA HD15 adaptors (with DIP
switches to select your preferred resolution and refresh rate), or even
cables hardcoding the monitor sense information. (I happen to have both
as well).

Anyway, back to your problem: the machine-independent rasops code is
indeed faulty (well, erasecols in rasops_bitops.h is), but this does not
show up on vax and hp300 because those special code (derived from X11R4
mfb X server code) for this operation.

I started to work on fixing rasops_bitops, to no avail so far [*], but
actually it will probably be much easier to move in the other direction,
and replace rasops_bitops with
known-to-be-good-from-years-of-actual-usage X11R4 derived code. Stay
tuned for a fix soon...

> It seems it will be hard to test all those <8bpp without mac68k. I
> couldn't find rasops2 use by anything else than macfb and rasops4
> was only use by macfb and lcd in arm/xscale/files.pxa2x0. (Or you
> have a way to virtually test them?)

2bpp and 4bpp modes are only used on mac68k (actually, 2bpp would be
used on NeXT systems too, but the port of the NetBSD/next68k code was
never completed due to a dire lack of interest). The ARM pxa lcd code
has theoretical support for 4bpp and 8bpp modes, but they have never
been used (or tested).

> Just to see, I rebooted my Mac in 2bit and 4bit color depth and my
> test case worked perfectly at those depth. Only in monochrome mode
> I have an issue with the 12bits wide font.

The problem gets exposed when a character cell width is not aligned on a
byte boundary; at 1bpp the 12x22 font character cell is 12 bits wide and
exposes the bug; at 2bpp or 4bpp it is either 24 or 48 bits wide, both
values being multiples of 8.

Miod

[*] I don't have enough contiguous working brain cells to be able to
work on smaller-than-8bpp code those days. And, unlike the X11 code, the
rasops is a bit overengineered in that it is designed to work on 32 bit
pixel blocks, but allows for computed bit positions over 32, by
accessing the next 32 bit chunk if necessary. And then there's a comment
mentioning that this causes macros to be too complex and probably goes
against compiler optimization. One more reason to try simpler,
real-world-proof code, instead.