How do I determine which monitors are attached to a system from a KMDF driver?

Question

I have a mouse HID which gives me co-ordinates on a monitor on a multi-monitor system. I would like my KMDF driver to map that onto the monitors such that the provided data [(x, y) on screen n] goes onto the monitor labelled "n" in the XP display-settings/properties or 7 screen-resolution panels.

I can find the screen data (resolution and relative positions) in the registry and map the co-ordinates OK, but I have no idea how to identify these monitors in the same way that the properties pages do. Can anyone point me in the right direction?

Answer 1

you need to have a helper user mode application query this config data and then send it to your driver. also note that for an aboslute pointing device, you are limited to the primary display, so it will be difficult to get absolute input to show upon 2ndary monitors

---

d -- This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 2

Thanks. I'll look into that. As well as the HID driver, I have a mouse filter which sets the MOUSE_VIRTUAL_DESKTOP flag and this results in absolute mouse data working well across all the additional monitors.

Answer 3

Many thanks for your suggestion; the helper app. has been working fine for a while. Now, however, I am being asked to provide a Service rather than an application so that the monitor set-up can be provided to the mouse hardware before log-in (so that the mouse works correctly on the log-in screen).

I have integrated the helper app. code into a fresh C++ service project which works fine under XP (finds both monitors with EnumDisplayMonitors) but which appears to find only 1 display (1024 x 768 - I have 800 x 600 and 1920 x 1080 monitors attached) using the EnumDisplayMonitors function and none using the QueryDisplayConfig function under Windows 7.

Do you know if I should expect to be able to get this data in a service with Windows 7?

Answer 4

why don't you try it out for yourself and see what happens?

---

d -- This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 5

I guess I didn't make that clear - I have integrated the helper app. code into a new C++ service project which works fine under XP (the service finds both monitors with EnumDisplayMonitors). However, under Windows 7, I have two choices, neither of which seems to work.

The Win2K DDM - the EnumDisplayMonitors function appears to find only 1 display (which is 1024 x 768 and does not correspond to either of my physical displays - I have 800 x 600 and 1920 x 1080 monitors attached) would this be a login pseudo-display?.

The Vista DDM QueryDisplayConfig function doesn't find any displays at all.

In both cases, the same code works fine in a user-mode helper application under both XP and 7. It would seem, therefore, that either:

     I need to configure the code differently for the service compared to the application; or

     the services session does not have access to the monitor configuration.

I have tried every modification/configuration that I think is reasonable to no good effect. And given the way Windows handles services differently from Vista onwards, I suspect the latter - that the display information may be considered specific to each user session and not available to the service's session. However I have been unable to find any documentation to indicate whether or not this is the case. That's what I would like either confirmed or denied so that I can proceed accordingly.

Confirmation might be a problem for me as I would like the display configuration at the login screen. Although this is not a problem if it were the case that all login sessions on multi-monitor systems are limited to a single screen - do you know if this is the case?

Answer 6

it could be that the information is stored per session. in XP, the service and the first logged in user both ran in session 0. on win7 (and vista), only services run in session zero and all logged in users run in their own separate session.

---

d -- This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 7

Do you know if / how I can find out for definite about this - the users of the system we have are a little underwhelmed by the non-availability of a the multi-monitor mouse at the first login screen (it is OK for later screens as the mouse driver has been informed of the monitor layout during previous logins)?

Answer 8

typically only the primary screen is used for winlogon, why do you need to force usage of the secondary monitors?

---

d -- This posting is provided "AS IS" with no warranties, and confers no rights.

Answer 9

It's a application for a high-value (and thus demanding) sector in which attention to detail is important. As you say, usually, only the primary is used; but we have had a specific user-request for it to operate at this stage (possibly just so that it gives the product a more solid feel, but possibly for a specific customisation). The mouse will work once the driver knows where the screens are, so I may just need to store the last-known configuration but a service feels like it would be a nicer solution.

Answer 10

You need your service to spawn an application running in the "on glass" process user context. That process can then enumerate adapters and their connected monitors in any version of the os from XP forward. You have to special case winlogon.exe, as it may be the "on glass process".  WTSQueryUserToken can return ERROR_NO_TOKEN or ERROR_NOT_LOGGED_ON, in which case you have to go get the security context for winlogon running in the console session.

See WTSGetActiveConsoleSessionId(), WTSQueryUserToken(), DuplicateTokenEx() CreateProcessAsUser(), etc on how to start a process with the correct user security context.

Once you have done that iterating over EnumDisplayDevices twice, once to find all the adapters and then again for each adapter to find the attached displays, works for all versions from XP forward.

---

Mark Roddy Windows Driver and OS consultant www.hollistech.com