* hw/kdrive/ephyr/ephyrhostvideo.c:
(EphyrHostXVAdaptorGetVideoFormats): properly get visual class instead of
returning the visual id.
(EphyrHostXVQueryEncodings): properly copy the fields because simple casting does
truncate some fields.
(EphyrHostAttributesDelete): XFree the whole array instead of trying to free invidial members.
* hw/kdrive/ephyr/ephyrvideo.c:
(ephyrInitVideo): fix a typo
(EphyrXVPrivQueryHostAdaptors): set XvWindowMask mask to adaptors type.
use host adaptor name. Don't forget to set nImages field.
(EphyrXVPrivRegisterAdaptors): report an error when KdXVScreenInit() fails.
* This patch adds multiscreen support to Xephyr. For instance,
the command line : "Xephyr :4 -ac -screen 320x240 -screen 640x480"
will launch with two "screens" - namely two main windows.
The first main window represents a screen that has the number :4.0, with
a geometry of 320x240 pixels, and the second one represents a screen
that has the number :4.1 with a geometry of 640x480.
The command line: "DISPLAY=:4.1 xclock" will launch the xclock program
on the second screen, for intance.
* this patch was edited by Dodji Seketeli <dodji@openedhand.com> for:
- better style compliance with the rest of the Xephyr code
- make sure Xephyr could be launched with no -screen option. By
default that creates a default screen of 640x480 pixel like before
- display full titles on the windows - with insctructions to grab
keyboard and mouse - like before.
* dix/events.c, include/dix.h:
(UpdateSpriteForScreen): added this to update the mouse sprite context
when we switch from a pScreen to another.
* mi/mipointer.c:
(miPointerWarpCursor): as we are switching to a new pScreen,
don't forget to update the mouse sprite context.
This adds hooks for the driver to access Create/DestroyPixmap and ModifyPixmapHe
ader.
It allocates a 0 sized pixmap using fb and calls the driver routine to do
work of allocating the actual memory.
ModifyPixmapHeader is mainly required for hooking the screen pixmap which
isn't create by normal methods
We only get core events through the EQ in exceptional cases, so make sure we
actually swap the core keymap for XI events as well. Gives us back the ability
to have multiple keyboard layouts simultaneously.
DGAStealXXXEvent modified to take in device argument.
The evdev driver only sends one valuator when only one axis changed. We need
to check for DGA either way (xf86PostMotionEventP), otherwise we lose purely
horizontal/vertical movements.
Note that DGA does not do XI events.
Center the frame around the first pointer found and then update all pointers
on the same screen to move to the edges (if necessary).
Note: xf86WarpCursor needs to be modified, is using deprecated
miPointerWarpCursor and will kill the server when called with
inputInfo.pointer.
Let the drivers only generate XI events and put those into the event queue.
When processing events, generate core events as needed. This fixes a number of
problems with XKB and the DIX in general.
The previous approach was to put core events and XI events as separate events
into the event queue. When being processed, the server had no knowledge of
them coming from the same device state change. Anything that would then change
the state of the device accordingly was in danger of changing it twice,
leading to some funny (i.e. not funny at all) results.
Emulating core events while processing XI events fixes this, there is only one
path that actually changes the device state now. Although we have to be
careful when replaying events from synced devices, otherwise we may lose
events.
Note: XI has precedence over core for passive grabs, but core events are
delivered to the client first.
This removes the wrapping added in 340911d724
We need it unconditionally in a few places, and the rest checked for NULL and
then set it to VCK anyway. So, fixing up all callers to appreciate the defined
return value.
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
Dodji Seketeli
Dodji Seketeli
Andrew Christan
Peter Hutterer
Dave Airlie
Kristian Høgsberg
Alan Coopersmith
Tilman Sauerbeck
Alan Hourihane
Michel Dänzer
Eamon Walsh