locked
Low-level monitor configuration API problems RRS feed

  • Question

  • I'm making some tests with the Monitor Configuration API and due to my needs I've got to use the low level functions.

    I've got no problems when the monitor is correctly plugged and set, however, if the monitor is in stand-by or another input is selected whenever I try to call either one of the low level or high level methods I get an error and my monitor completely stops responding to any of its buttons, I need to cut its power source and reconnect it. Tested on two completely different hardware configurations, and the previous call to GetNumberOfPhysicalMonitorsFromHMONITOR is correctly returning all the values.

    It seems the amount of people using this API can be counted with the fingers of one hand and doesn't talk about this case.

     My code is written using VB.NET, and the API is declared as:

        Private Class NativeMethods

            <StructLayout(LayoutKind.Sequential, CharSet:=CharSet.Auto)>
            Public Structure PHYSICAL_MONITOR
                Public hPhysicalMonitor As IntPtr

                <MarshalAs(UnmanagedType.ByValTStr, SizeConst:=128)>
                Public szPhysicalMonitorDescription As String
            End Structure

            Public Enum LPMC_VCP_CODE_TYPE
                MC_MOMENTARY
                MC_SET_PARAMETER
            End Enum

            <DllImport("user32.dll", EntryPoint:="MonitorFromWindow")> _
            Public Shared Function MonitorFromWindow(ByVal hwnd As System.IntPtr, ByVal dwFlags As UInteger) As System.IntPtr
            End Function

            <DllImport("dxva2.dll", EntryPoint:="GetNumberOfPhysicalMonitorsFromHMONITOR", SetLastError:=True)>
            Public Shared Function GetNumberOfPhysicalMonitorsFromHMONITOR(hMonitor As IntPtr, ByRef pdwNumberOfPhysicalMonitors As UInteger) As Boolean
            End Function

            <DllImport("dxva2.dll", EntryPoint:="GetPhysicalMonitorsFromHMONITOR", SetLastError:=True)>
            Public Shared Function GetPhysicalMonitorsFromHMONITOR(hMonitor As IntPtr, dwPhysicalMonitorArraySize As UInteger, <Out()> pPhysicalMonitorArray As PHYSICAL_MONITOR()) As Boolean
            End Function

            <DllImport("dxva2.dll", EntryPoint:="DestroyPhysicalMonitors", SetLastError:=True)>
            Public Shared Function DestroyPhysicalMonitors(dwPhysicalMonitorArraySize As UInteger, pPhysicalMonitorArray As PHYSICAL_MONITOR()) As Boolean
            End Function

            <DllImport("dxva2.dll", EntryPoint:="GetCapabilitiesStringLength", SetLastError:=True)>
            Public Shared Function GetCapabilitiesStringLength(hMonitor As IntPtr, <Out()> ByRef pdwCapabilitiesStringLengthInCharacters As UInteger) As Boolean
            End Function

            <DllImport("dxva2.dll", EntryPoint:="CapabilitiesRequestAndCapabilitiesReply", SetLastError:=True)>
            Public Shared Function CapabilitiesRequestAndCapabilitiesReply(hMonitor As IntPtr, <Out(), MarshalAs(UnmanagedType.LPStr)> pszASCIICapabilitiesString As System.Text.StringBuilder, dwCapabilitiesStringLengthInCharacters As UInteger) As Boolean
            End Function

            <DllImport("dxva2.dll", EntryPoint:="GetVCPFeatureAndVCPFeatureReply", SetLastError:=True)>
            Public Shared Function GetVCPFeatureAndVCPFeatureReply(hMonitor As IntPtr, bVCPCode As Byte, <Out()> ByRef pvct As LPMC_VCP_CODE_TYPE, <Out()> ByRef pdwCurrentValue As UInteger, <Out()> ByRef pdwMaximumValue As UInteger) As Boolean
            End Function

            <DllImport("dxva2.dll", EntryPoint:="SetVCPFeature", SetLastError:=True)>
            Public Shared Function SetVCPFeature(hMonitor As IntPtr, bVCPCode As Byte, dwNewValue As UInteger) As Boolean
            End Function

        End Class

    Anyway, I repeat, it works as expected when the monitor is not in stand mode and with the input source set to a different one. I could somewhat expect the API not to work otherwise (although I don't see the standards saying so), but not to completely freeze the control panel.

    Has anyone else run into this problem or have some extra info to share?

    Monday, February 17, 2014 10:46 AM

All replies

  • OK, after some more tests I've found out that this is happening when using a HDMI cable. If I use a RGB one, everything works as expected. Again, I've tried two completely different hardware configurations.

    Is this a HDMI cable flaw and I should try with a third one, is this because some line in the cable stops working when the signal isn't available, or maybe is this some power save feature in Windows?

    Monday, February 17, 2014 3:06 PM
  • Hello.

    Yes power state can be a problem. I know that win32 API can handle USB de/connection via Windows Messages (Message Loop). Perhaps the same apply for power state, video cable de/connection and so on. You have to check the API. It is just an idea.

    Check this :  WM_SETTINGCHANGE and this power state




    • Edited by Miaou77 Monday, February 17, 2014 8:30 PM
    Monday, February 17, 2014 8:20 PM
  • However that wouldn't be a proper solution. What if the monitor is off before the application runs? the application would try to check the monitor status and the control panel would end blocked...

    I've read about a lot of people having problems with Windows 7 and HDMI, so I'm thinking about testing some Windows 8 or even Vista installation just for the record.

    Tuesday, February 18, 2014 8:50 AM
  • Hello.

    Your control panel wouldn't end blocked. It seems you don't know how to use thread to not block panel. If the monitor is off before the application runs, you just have to wait, and test monitor return inside a thread or a timer.

    Check multithreading programming over the net.

    Tuesday, February 18, 2014 12:52 PM
  • It seems you haven't fully read my original message, the control panel getting stuck is the physical one in the monitor, not my user interface. All the buttons in the monitor (and I've tested up to three different models, using three different computers) stop responding until I cut its power source and connect it again.

    So far this seems to be a Windows 7 issue, I've read a lot of reports from people having problems with HDMI and Windows 7 that seem to relate to this. I've yet to try my application in some Windows 8.1 or even Vista installation. Also, it seems some graphic cards and its drivers offer some options to workaround this problem. Will update again after I make the tests.

    Tuesday, February 18, 2014 3:48 PM
  • Hello.

    Sorry if i've misunderstood. I'm not good at english.

    We can't really help you because it is not a MediaFoundation problem. I hope you find a solution.

    Tuesday, February 18, 2014 8:31 PM