Desperately want GDIINFO, how can I obtain this structure?

[Tim Roberts]

See my another post. You still think that does not make sense? I also know
that the only way out is KM display driver filter, I just cannot believe
that obtaining such a simple structure needs a driver programming...

I'm not sure why you are so surprised. The information you are asking for
is EXTREMELY device-specific, and provides virtually no useful value for
applications. Why should Windows make it available?

Further, in the majority of cases, the information you want is just not
knowable. On a laptop that ships with a specific LCD panel, MAYBE the
display driver has a table that indicates the pixel characteristics for
that display. For a CRT, that information is not even available to the
driver.

You may have to resign yourself to doing your studies on a very specific
hardware setup, on which you can determine the pixel characteristics using
the debugger approach identified earlier in the thread.

 

[Brian Catlin]

I'm not sure why you are so surprised. The information you are asking for
is EXTREMELY device-specific, and provides virtually no useful value for
applications. Why should Windows make it available?

I think that's going a little too far. There are at least several reasons why
someone might want to know the pixel stripe layout for a screen. Personally, I
think all the GDIINFO data should be available via GetDeviceCaps. If there's
one thing I can't stand, its other people telling me what I can and can't know

Further, in the majority of cases, the information you want is just not
knowable. On a laptop that ships with a specific LCD panel, MAYBE the
display driver has a table that indicates the pixel characteristics for
that display.

The graphics controller in a laptop certainly has to know how the pixel stripe
layout, although whether the driver knows it is another issue.

For a CRT, that information is not even available to the driver.

Not necessarily. As I recall, there is no EDID information on this, but the
characteristics of some CRTs are well known, and the driver *could* know that.

You may have to resign yourself to doing your studies on a very specific
hardware setup, on which you can determine the pixel characteristics using
the debugger approach identified earlier in the thread.

Agreed. The general purpose solution of an intermediate display driver is well
beyond the capabilities of most driver writers

-Brian

Brian Catlin, Sannas Consulting 310-944-9492
Windows Network, Video, WDM Device Driver Training & Consulting
See WWW.AZIUS.COM.bad for courses and scheduling
REMOVE .BAD FROM EMAIL AND WEB ADDRESS

 

[Brian Catlin]

Hi Brian,

Thank you very much for your help! At the first glance I feel very happy and
thought the good approach of obtaining the info I want has been discovered.
After some digestion I found that you meant that this method is no longer
available in current or newer OS.... :=) since I am developing on Windows XP
and hope that I can find a (almost) universal way to handle Windows family
together(at least Windows 2000 to Windows XP...) so this method does not
work, I guess? If I finally cannot find a universal way, then I guess I'd
better come back to this one...

What I would do if I were you, would be to post a request in the WinDbg
newsgroup, and ask if you can get a version of GDIKDX.DLL for XP. Otherwise,
you can always do it by hand in the debugger, or even write your own debugger
extension DLL to automate the process and fetch the data that you need

-Brian

Brian Catlin, Sannas Consulting 310-944-9492
Windows Network, Video, WDM Device Driver Training & Consulting
See WWW.AZIUS.COM.bad for courses and scheduling
REMOVE .BAD FROM EMAIL AND WEB ADDRESS

 

[Brian Catlin]

Hi Brian,

do you mean that the "tracing by debugging" method does not apply on any OS
after win2000,

No, the GDIKDX DLL doesn't ship with the debugger for operating systems later
than Win2K

but once one get the offset address in that global structure, the offset
won't change in WinXP,

Correct - at least until a hotfix or service pack changes it. As long as you
don't install any upgrades, the offsets will remain constant

so the result I obtained in Win2000 should work for WinXP?

It's probably pretty close

-Brian

Brian Catlin, Sannas Consulting 310-944-9492
Windows Network, Video, WDM Device Driver Training & Consulting
See WWW.AZIUS.COM.bad for courses and scheduling
REMOVE .BAD FROM EMAIL AND WEB ADDRESS

 

[Brian Catlin]

Hi Vipin,

Thank you very much for always taking care of my questions :=) that's really
a great idea. Will this make our program locked on ATI card? I am wondering
if a GDI filter really needs to hang on with a partilular display card and
be dependent on that card? Then if the user has another card, my program
won't work?

A GDI filter (or intermediate display driver) will work with any vendor's
hardware. Vipin's idea of getting ATI to add an escape code to their driver,
will obviously be ATI dependent

-Brian

Brian Catlin, Sannas Consulting 310-944-9492
Windows Network, Video, WDM Device Driver Training & Consulting
See WWW.AZIUS.COM.bad for courses and scheduling
REMOVE .BAD FROM EMAIL AND WEB ADDRESS

 

[lucy]

I think that's going a little too far. There are at least several reasons why
someone might want to know the pixel stripe layout for a screen. Personally, I
think all the GDIINFO data should be available via GetDeviceCaps. If there's
one thing I can't stand, its other people telling me what I can and can't know

The graphics controller in a laptop certainly has to know how the pixel stripe
layout, although whether the driver knows it is another issue.


Not necessarily. As I recall, there is no EDID information on this, but the
characteristics of some CRTs are well known, and the driver *could* know that.

Agreed. The general purpose solution of an intermediate display driver is well
beyond the capabilities of most driver writers

Oh, I did not know the gdi display filter driver is so difficult to write? I
am not even a driver writer...

 

[lucy]

What I would do if I were you, would be to post a request in the WinDbg
newsgroup, and ask if you can get a version of GDIKDX.DLL for XP. Otherwise,
you can always do it by hand in the debugger, or even write your own debugger
extension DLL to automate the process and fetch the data that you need

I am just worrying about how long will this hacked offset be valid in
Windows XP, or even other Windows system? suppose I get the offset of
GDIINFO in PDEF using this Windbg method?

As you said, a patch from M$ may change the offset, then I shall find the
offset by Windbg method again, am I right? Due to security concern, users
definitely need to keep their patch updated all the time. So I have to find
the offset by Windgb method again and again for different users using
different OS with different version of patch?

"even write your own debugger
extension DLL to automate the process and fetch the data that you need"

Yeah, eventually, in order to find the offset by Windgb method again and
again for different users using different OS with different version of
patch, I guess I should do this automation...

I am just wondering about the time-investment between this method and the
display filter approach...

Thank you very much Brian! you pointed out to me a very good alternative...

-Lucy

 

[Brian Catlin]

I am just worrying about how long will this hacked offset be valid in
Windows XP, or even other Windows system? suppose I get the offset of
GDIINFO in PDEF using this Windbg method?

As I pointed out, this method is a bit of a hack, and a given offset could
change with a hotfix or service pack

As you said, a patch from M$ may change the offset, then I shall find the
offset by Windbg method again, am I right? Due to security concern, users
definitely need to keep their patch updated all the time. So I have to find
the offset by Windgb method again and again for different users using
different OS with different version of patch?
Yes

"even write your own debugger
extension DLL to automate the process and fetch the data that you need"

Yeah, eventually, in order to find the offset by Windgb method again and
again for different users using different OS with different version of
patch, I guess I should do this automation...

The extension DLL would also have to be changed if an update changes the offsets

I am just wondering about the time-investment between this method and the
display filter approach...

Writing a driver of this type is beyond most driver writer's abilities; however,
it is guaranteed to work regardless of what changes are made to the system

-Brian

Brian Catlin, Sannas Consulting 310-944-9492
Windows Network, Video, WDM Device Driver Training & Consulting
See WWW.AZIUS.COM.bad for courses and scheduling
REMOVE .BAD FROM EMAIL AND WEB ADDRESS

 

[Severian]

I'm not sure why you are so surprised. The information you are asking for
is EXTREMELY device-specific, and provides virtually no useful value for
applications. Why should Windows make it available?

Further, in the majority of cases, the information you want is just not
knowable. On a laptop that ships with a specific LCD panel, MAYBE the
display driver has a table that indicates the pixel characteristics for
that display. For a CRT, that information is not even available to the
driver.

I believe it's also available to the driver when LCD displays are
connected digitally. IIRC, ClearType uses it when it's available.

Sub-pixel antialiasing for vector drawing, (a la ClearType) would
certainly find the information useful.