I don't think we want to ignore virtual EnterNotify events.
As per the spec, those happen when the cursor moves from an ancestor of the Wine window directly to one of its children. AFAICT, the only potential child of a Wine whole window is a drawable client for OpenGL or Vulkan. So I think we only get a virtual EnterNotify in two cases:
1. When using a window manager that adds decoration, we get one when moving from that decoration directly to the client window.
2. In situations where the cursor starts over an ancestor of a Wine window and moves directly to the client window. This can happen, e.g., when running without a window manager (or with one that doesn't create a desktop). In that case, moving the cursor from the root window to the client window will be a virtual EnterNotify.
In both scenarios, ignoring the EnterNotify isn't usually a big deal, since there will be follow-up MotionNotify events. However, in case 2, if the window is mapped under the cursor and the user never moves the mouse, Wine is left very confused. (See MR !1250 for another attempted approach to that issue. There are other problems with the current approach, but I think this is correct regardless.)
If there are potentially other child windows, we could limit this to cases where the event's `subwindow` is equal to the driver's window data's `client_window`.