I am attempting to detect when my TV is connected to my laptop via HDMI cable. I am using the WinAPI function RegisterDeviceNotification() to handle device messages.
When I connect my TV to my laptop (via HDMI cable) I never receive a WM_DEVICE_ARRIVAL message, only 3 WM_DEVICE_CHANGE events. Is this normal?
I really need the WM_DEVICE_ARRIVAL event because the lParam(or wParam, I forget) contains a structure that tells me the type of device connected and the device name whereas, afaik, the WM_DEVICE_CHANGE event does not contain this structure.
If its normal to not receive a WM_DEVICE_ARRIVAL message upon HDMI port insertion, what other method could I use to determine the devices name and type when its connected?
My only idea is: list all devices upon application startup, upon device connection react to the WM_DEVICE_CHANGE event and see if the list of devices has increased.
You could poll GetSystemMetrics(SM_CMONITORS) or EnumDisplayMonitors.
The WM_SETTINGCHANGE message is (usually) sent by applications and services which change system metrics, including the desktop resolution (which changes when HDMI is plugged if the desktop is extended, it wouldn't for mirroring). You could use this to trigger the above polling, instead of relying solely on a timer.
Related
Good day! I write a windows service, which detects USB Flash drive connection and do something with connected drive. And now after tests i need to reprocess devices after wake up from sleep mode. I solve this problem when service work as windows program. To solve i additionally process DBT_DEVNODES_CHANGED, but service don't receive this message, it receives only DBT_DEVICE_ARRIVAL and DBT_DEVICEREMOVECOMPLETE. I also tried to check all messages handled by service except SERVICE_CONTROL_DEVICEEVENT and SERVICE_CONTROL_STOP when system is going to sleep and i don't get any message.
How can I determine when the system is waking up?
A normal application receives a WM_POWERBROADCAST:PBT_APMRESUMEAUTOMATIC window message, but a service will not get this message if it does not have a window. However, a service can receive SERVICE_CONTROL_POWEREVENT in its HandlerEx callback function, with the same parameters as WM_POWERBROADCAST
Notifies a service of system power events. The dwEventType parameter contains additional information. If dwEventType is PBT_POWERSETTINGCHANGE, the lpEventData parameter also contains additional information.
On Windows 8 and later, you can also use the PowerRegisterSuspendResumeNotification() function:
Registers to receive notification when the system is suspended or resumed.
The service equivalent of WM_DEVICECHANGE is SERVICE_CONTROL_DEVICEEVENT:
Notifies a service of device events. (The service must have registered to receive these notifications using the RegisterDeviceNotification function.) The dwEventType and lpEventData parameters contain additional information.
The best way to detect that system is waking up is process power messages.
Windows must process WM_POWERBROADCAST
Services must add SERVICE_ACCEPT_POWEREVENT to last call to SetServiceStatus and process SERVICE_CONTROL_POWEREVENT
My error was very stupid. I forget to add SERVICE_ACCEPT_POWEREVENT.
Once my embedded device is connected to USB port of my PC, it should trigger an exe as an event. How can I achieve this??
Should I create a service to keep monitoring the USB connector bus or is there any default API's available in Windows to achieve this??
thanks.
A simple exe which is started on connect is not possible. But you can write a service or user mode application which listens for device arrival events. WM_DEVICECHANGE is sent to all (registered) applications with a device interface guid which represents which device is plugged in. You can then use this id with the setupapi to see if its your device.
On receiving that event, you can then start your executable.
Depending on your version of Windows it might be possible with a workaround using a AutoRun.inf file in the root folder of a USB drive. For security reasons this is by default turned off, and in Windows 7 not allowed at all.
To achieve the same effect in a more robust way, you need to create a service that monitors whether your device is connected or not (e.g. iTunesHelper that monitors for connected Apple devices).
The easiest solution is probably a trivial UMDF driver. That's basically a small COM component called when your device is connected.
I'm trying to detect the event when a FireWire cable is plugged into the FireWire port of the PC withing MFC C++ app. I would also like to trigger this even myself as the FireWire connections drops and never is rediscovered withing unplugging the cable and plugging it back in.
Anyone have any experience trying to programmaticaly simulate a unplug-replug event?
You can register yourself to receive device arrival messages. See the help for RegisterDeviceNotification to find an example on how to register yourself.
You can trigger a bus reset notification on the firewire bus, but I don't know if you can do this from user mode, without the help of a kernel mode module.
I am monitoring HID connections using EnumDevices(..., DIEDFL_ATTACHEDONLY). When I disconnect a game controller it no longer shows up in the callback. However, when I disconnect the keyboard, it still shows up in EnumDevices.
I've looked through the API, but I don't see where else to query if a device is connected.
What about http://msdn.microsoft.com/en-us/library/windows/desktop/aa363432%28v=vs.85%29.aspx
You can subscribe to any device notifications like attach,detach,etc...
I"m working on a C++ Win32 application for which I'm trying to essentially "auto detect" if a device has been plugged into one of the RS232 ports and then if it has been disconnected.
The checking for a connected device is easy enough because my use case allows me to assume that this particular thread will be the first to try to initiate communication with the port. I'm able to scan the available ports every minute or so and once I've found a port with the device on it I flag that port has having a device, close the port, then set an event so that the process that actually will use the device knows it can now connect on that port.
The disconnect detect is where I run into trouble. When I'm scanning for connected devices I can actually send data to the port to be sure that, if there is a device, it's the specific device I'm looking for. But once it's connected, that port will already be open by the other process and I can no longer open that port from the detect thread. So I am looking for a way to either open the port in a "listen mode" or something like that so I can just see if the device is still there.
I briefly came across something about watching the DSR or DTR line or something...but couldn't find any more or how to actually do it.
Any suggestions?
Edit: Looks like I need to clarify a little more... For detecting the disconnect, I cannot send data to the RS232 port in any way. Also, I cannot assume that another application actually has the port open. The device may be physically connected, but without and open connection...but I still can't risk sending data to it. I was hoping there was a way to just check that there was still power on that port or something like that.
It depends on the connected hardware whether there will be a change in the modem state registers when you disconnect the hardware, but if there is then you could check the state of for example the CTS or DSR line using the GetCommModemStatus() function.
There is however the problem that you need a file handle to the COM port to call any API function, and this is exclusive as the documentation of CreateFile() states:
The CreateFile function can create a handle to a communications resource, such as the serial port COM1. For communications resources, the dwCreationDisposition parameter must be OPEN_EXISTING, the dwShareMode parameter must be zero (exclusive access)
So you can not open the COM port to watch the line state while another process has the port opened for communication.
There are ways to do this, but they involve a driver. SysInternals has the Portmon tool, and a Google search will turn up some companies selling software for sharing COM port access between applications, but AFAIK simultaneous access is impossible using the standard API.
Sounds like it might be a good idea to have that process that will give notification of connected and disconnected events also relay the data to the other process. Have your app work in layers such that there is a process that takes control of the RS232 connection and sends your upper layer app events: connected, disconnected, data available, etc.
I have done applications like this and its not really a language specific problem (unless you have no serial port access in your language).
My preferred solution has always been to have one thread per port, according to your configuration and the thread maintains a state which is accessible from some sort of controller.
The default condition is that the thread polls the port every few seconds and while there is no answer assume there is no device connected. Once a device seems to respond, change the state to indicate this is so.
I designed an application that had a number of queues: One with disconnected threads, one with connected, but idle threads and another with connected and busy threads. The controller moved threads between queues as they changed state.