Hi!
The only problem were subpixel types - there the pionter would also need to have "pixel offset". Per-bpp functions can ignore it altogether for >=8bpp, but it still creates some mess. Both "normal" and "Raw" functions accessing the context should do this "shifting". Should it be done in PutPixel or GP_PIXEL_ADDR/OFFSET (more general and probably right, but even messier)?
Well I know you hate to hear that, but there are really > 8BPP byte unaligned pixel types 19BPP for example (which is supported by linux on arm targets and yes I have such hardware). But the solution should be the same as for subbyte pixels.
"Hate" is not right. If there is such a word, I would hesitate to write it down.
[with curiosity replacing loathing for a moment] How is 19bpp used/divided? And what hardware? Is it on 19bit Harvard-type processors supporting ternary arithmetic while driving on the left side of the road?
Not really that strange; PXA ARM processors supports 19BPP and 18BPP hardware displays. The display lines (at least) are byte aligned. The kernel framebuffer then gives you buffer to write to, which is, for example, 19BPP. And such displays are not that uncommon on ARM machines.