Display driver problem

Hi All,

We are developing controller boxes of multi-screen display walls. The
computers run Microsoft Windows 2000 or Windows XP.
We integrate our own developed graphic controller boards in the computer
boxes, and we have developed a display driver, which is able to handle
multiple graphics devices to compose a large coherent desktop.

If so many boards are installed to a system, that the resulting desktop
exceeds the size of 16K pixels (16384) either horizontally, or
vertically, we found that Windows does not draw correctly.

Microsoft Platform SDK says that the dimensions of the ‘Virtual Screen’ are:

SHORT_MIN <= rcVirtualScreen.left <= SHORT_MAX - 1
SHORT_MIN +1 <= rcVirtualScreen.right <= SHORT_MAX
SHORT_MIN <= rcVirtualScreen.top <= SHORT_MAX - 1
SHORT_MIN +1 <= rcVirtualScreen.bottom <= SHORT_MAX

we found that Windows draws correctly within the desktop coordinate
space [-16384,-16384]…[16383,16383] only. The area where the drawing
operations are correct:

-16384 <= rcVirtualScreen.left <= 16383 - 1
-16384 +1 <= rcVirtualScreen.right <= 16383
-16384 <= rcVirtualScreen.top <= 16383 - 1
-16384 +1 <= rcVirtualScreen.bottom <= 16383

The symptoms are the followings:

  • The portions of the desktop falling out of the space described above
    are not updated correctly. E.g. moving a window in these areas from one
    position to another, the area of the original window position is not
    redrawn.
  • The drawing functions do not draw either, or do not draw correctly in
    the areas that fall out of the -16K … +16K coordinate space.
  • Only those drawing operations can produce correct output that the
    driver implements accelerated functions for.

To make sure that the problem is independent of our display driver, we
have set up a ten-screen system using Matrox G450 MMS graphics boards.
We have configured the ten monitors to place in a single row, each
monitor had the resolution 1920x1440. The leftmost monitor was
configured to be the primary one. So the right edge of the desktop was
beyond the coordinate 16384.
This system could also demonstrate the same drawing error.

Is there a way to extend this limit to the documented [-32K;32K] range
instead of [-16K;16K]?

Thank you,
Miklos Szegedi

mailto: xxxxx@dexonsystems.com

Exactly. The clipping region engine in USER uses 16bit integers.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Miklos Szegedi”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, January 25, 2005 1:10 PM
Subject: [ntdev] Display driver problem

> Hi All,
>
> We are developing controller boxes of multi-screen display walls. The
> computers run Microsoft Windows 2000 or Windows XP.
> We integrate our own developed graphic controller boards in the computer
> boxes, and we have developed a display driver, which is able to handle
> multiple graphics devices to compose a large coherent desktop.
>
> If so many boards are installed to a system, that the resulting desktop
> exceeds the size of 16K pixels (16384) either horizontally, or
> vertically, we found that Windows does not draw correctly.
>
> Microsoft Platform SDK says that the dimensions of the ‘Virtual Screen’ are:
>
> SHORT_MIN <= rcVirtualScreen.left <= SHORT_MAX - 1
> SHORT_MIN +1 <= rcVirtualScreen.right <= SHORT_MAX
> SHORT_MIN <= rcVirtualScreen.top <= SHORT_MAX - 1
> SHORT_MIN +1 <= rcVirtualScreen.bottom <= SHORT_MAX
>
> we found that Windows draws correctly within the desktop coordinate
> space [-16384,-16384]…[16383,16383] only. The area where the drawing
> operations are correct:
>
> -16384 <= rcVirtualScreen.left <= 16383 - 1
> -16384 +1 <= rcVirtualScreen.right <= 16383
> -16384 <= rcVirtualScreen.top <= 16383 - 1
> -16384 +1 <= rcVirtualScreen.bottom <= 16383
>
> The symptoms are the followings:
> - The portions of the desktop falling out of the space described above
> are not updated correctly. E.g. moving a window in these areas from one
> position to another, the area of the original window position is not
> redrawn.
> - The drawing functions do not draw either, or do not draw correctly in
> the areas that fall out of the -16K … +16K coordinate space.
> - Only those drawing operations can produce correct output that the
> driver implements accelerated functions for.
>
> To make sure that the problem is independent of our display driver, we
> have set up a ten-screen system using Matrox G450 MMS graphics boards.
> We have configured the ten monitors to place in a single row, each
> monitor had the resolution 1920x1440. The leftmost monitor was
> configured to be the primary one. So the right edge of the desktop was
> beyond the coordinate 16384.
> This system could also demonstrate the same drawing error.
>
> Is there a way to extend this limit to the documented [-32K;32K] range
> instead of [-16K;16K]?
>
> Thank you,
> Miklos Szegedi
>
> mailto: xxxxx@dexonsystems.com
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Last time I checked, 16 bit signed integers cover the range -32768 …
32767.

The limit he is describing is that of 15 bit signed integers.

MH.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: 25 January 2005 14:34
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Display driver problem

Exactly. The clipping region engine in USER uses 16bit integers.

This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.

Hi,

Exactly. Does Windows use 15 bit signed integers here? But why does
Platform SDK docs say 16bit integers then?
Is that one bit reserved for special use?

Thanks,
Mike

Last time I checked, 16 bit signed integers cover the range -32768 …
32767.

The limit he is describing is that of 15 bit signed integers.

MH.