gdiinfo.ulPrimaryOrder in monolithic printer driver

NTDEV
1

I have a monolithic printer driver which outputs 24 bit color raster
data. Until recently, however, all the printers we supported were
monochrome. We are currently investigating a color device and found
that the color output from the driver is partially reversed (red comes
out blue, blue comes out red, but green comes out green).

The driver answers DC_COLORDEVICE true; the devmode’s dmColor field is
set to DMCOLOR_COLOR (and dmFields has the DMCOLOR flag set). The
drivers gdiinfo.ulPrimaryOrder is PRIMARY_ORDER_ABC, which I understand
from MSDN to mean RGB order. Other gdiinfo members which may be
important are:
cBitsPixel = 24;
cPlanes = 1;
ulDACRed = 8;
ulDACGreen = 8;
ulDACBlue = 8;
ulNumColors = 256;
flRaster = 0;

When the driver gets a 24-bit bitmap to output, the data is actually in
BGR order.

Changing ulPrimaryOrder to any other value has no effect on the data
that comes in to the driver, it is always in BGR order.

What do I need to do to convince Windows that my driver needs the data
in RGB order?

Or do I have to copy the raster data & swap the bytes?

Thanks,
ScottR

2

Robins, Scott wrote:

I have a monolithic printer driver which outputs 24 bit color raster
data. Until recently, however, all the printers we supported were
monochrome. We are currently investigating a color device and found
that the color output from the driver is partially reversed (red comes
out blue, blue comes out red, but green comes out green).

The driver answers DC_COLORDEVICE true; the devmode’s dmColor field is
set to DMCOLOR_COLOR (and dmFields has the DMCOLOR flag set). The
drivers gdiinfo.ulPrimaryOrder is PRIMARY_ORDER_ABC, which I understand
from MSDN to mean RGB order. …

When the driver gets a 24-bit bitmap to output, the data is actually in
BGR order.

Sure. That’s the format of a standard 24-bit DIB. GDI will generally
hand you bitmaps as it receives them. When you get a format you don’t
like you can call back into GDI to convert it, but in this case it’s
probably easier to just swap them yourself.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

> Sure. That’s the format of a standard 24-bit DIB. GDI will generally
hand you bitmaps as it receives > them. When you get a format you don’t
like you can call back into GDI to convert it, but in this case > it’s
probably easier to just swap them yourself.

Well, what’s the point of ulPrimaryOrder if you’re always going to get
the data in BGR order?

Thanks,
ScottR

4

Robins, Scott wrote:

> Sure. That’s the format of a standard 24-bit DIB. GDI will generally
>
hand you bitmaps as it receives > them. When you get a format you don’t
like you can call back into GDI to convert it, but in this case > it’s
probably easier to just swap them yourself.

Well, what’s the point of ulPrimaryOrder if you’re always going to get
the data in BGR order?

ulPrimaryOrder tells GDI the format of YOUR surface. GDI can draw
directly on your surface for the operations you do not support. To do
that, it has to know the exact format of your surface. It does not
promise to convert every bitmap to your format before calling you. It
CAN do so, if you call back to GDI, but since many graphics engines can
do colorspace-converting blits now, it makes sense to hand the driver
the raw format first.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5


Thanks Tim.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, November 09, 2006 1:52 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] gdiinfo.ulPrimaryOrder in monolithic printer driver

Robins, Scott wrote:

> Sure. That’s the format of a standard 24-bit DIB. GDI will
> generally
>
hand you bitmaps as it receives > them. When you get a format you
don’t like you can call back into GDI to convert it, but in this case
> it’s probably easier to just swap them yourself.

Well, what’s the point of ulPrimaryOrder if you’re always going to get

the data in BGR order?

ulPrimaryOrder tells GDI the format of YOUR surface. GDI can draw
directly on your surface for the operations you do not support. To do
that, it has to know the exact format of your surface. It does not
promise to convert every bitmap to your format before calling you. It
CAN do so, if you call back to GDI, but since many graphics engines can
do colorspace-converting blits now, it makes sense to hand the driver
the raw format first.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer