Not sure what I was thinking when I wrote this... it would cause the box
coordinates to be off for exaCopyNtoNTwoDir or fallbacks.
Thanks to Tilman Sauerbeck for pointing out the problem on IRC and testing the
fix.
Matches linuxPci.c changes made in 8279444a54
Fixes compiler errors:
"ix86Pci.c", line 194: too many struct/union initializers
"ix86Pci.c", line 204: too many struct/union initializers
"ix86Pci.c", line 214: too many struct/union initializers
Instead of hardcoding CoreProcessPointerEvent, actually try to unwrap properly
and then call the unwrapped processInputProc. Seems to be a better idea,
especially since it makes stuff actually work...
Followup to [1].
If a core grab causes the device to freeze, it overwrites the processInputProc
of the device. [1] would then overwrite this while unwrapping, the device
does not thaw anymore.
Changing this to only re-wrap if the processInputProc hasn't been changed
during the event handling.
[1] 340911d724
When processing events from the EQ, _always_ call the processInputProc of the
matching device. For XI devices, this proc is wrapped in three layers.
Core event handling is wrapped by XI event handling, which is wrapped by XKB.
A core event now passes through XKB -> XI -> DIX.
This gets rid of a sync'd grab problem: with the previous code, core events
did disappear during a sync'd device grab on account of mieqProcessInputEvents
calling the processInputProc of the VCP/VCK instead of the actual device. This
lead to the event being processed as normal instead of being enqueued for
later replaying.
Even though they're defined to zero by the spec, we've seen an EDID block
where the (empty) ASCII strings were stuffed in a byte early, leading to the
descriptor being considered a detailed timing instead.
GenericEvents can't be parsed to keyButtonPointer, and there's no guarantee
that it has a time field anyway. PlayReleasedEvent needs to store the millis
when we know it (core events, XI event) and just re-use them for GenericEvents.
Yes, this is a hack. But it looks like the time has zero significance anyway.
If the driver isn't compatible to the server, all bets are off anyway wrt
the contents of the fields that we're validating, which can lead to bogus
error messages.
The only functional changes in this patch are a removal of use of
Xtrans internals -- replaced by xcb, which doesn't seem to be used
elsewhere in the server? Pity.
Also, a fix to make all X11 windows pop to the front of the display
when the X11.app icon is clicked -- currently takes two clicks,
not sure why.
