Re: gpx(4) color framebuffer driver for VS3100/m30

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

ragge@ wrote:

> > I'm not sure current status of NetBSD/vax on VS3100, especially
> > framebuffers, but I'll commit the driver if there is no particular
> > objection.
> Great work!  This is one of the devices that I have never been able to 
> test :-)

Thanks ;-)

> Please go ahead!

I've updated diffs:

 https://github.com/tsutsui/netbsd-src/compare/3013c7cb346682f89f992238794c438d22702e20...tsutsui:netbsd-src:tsutsui-vax-gpx

- fix ioctl return values (OpenBSD doesn't use EPASSTHROUGH)
- no need to allocate resources for smg(4) on attach if it's done
  in early cninit
- misc cosmetics (remove unnecessary includes, reorder includes etc.)

I'll commit this once after I check smg(4) console (without gpx(4) option)
actually attached via consinit(9) on my VS3100/m30.

Then I've also ported OpenBSD's rasops(9)'fied smg(4) driver:

 https://github.com/tsutsui/netbsd-src/compare/tsutsui:netbsd-src:tsutsui-vax-gpx...tsutsui:netbsd-src:tsutsui-vax-smg-rasops

This means we can use various fonts (i.e. other than R2L and 8x15 size
qvss8x15) on smg(4).

It looks smg(4) has VRAM in WSDISPLAY_FONTORDER_R2L bit order,
i.e. LSBit in byte is the most left side pixel, so we cannot use
current MI rasops1 ops (putchar and cursor for 1bpp) as is.

OpenBSD modified MI rasops_mask.[ch] in sys/dev/rasops to flip
bit orders of mask values for 1bpp bitmap mask ops on LITTLE_ENDIAN:
 https://github.com/openbsd/src/commit/527530de9ad5381dffe3768a1c5bda867e1652dc

However I'm afraid we have to consider more complex cases because
there are LITTLE_ENDIAN machines that have L2R bit order VRAMs
(i.e. MSBit in byte is the most left side pixel), so I prepared
smg(4) specific putchar and cursor ops (pulled from old luna68k),
and also modified bitmap mask values for copycols and erasecols ops
(so that we can avoid a call for review on tech-kern@ :-p).

I'll also commit this changes (in a separate commit) later.

Have fun,
---
Izumi Tsutsui