xextproto had Xlib client headers moved into libXext.
Protocol header files are named fooproto.h, header files with constants
foo.h or fooconst.h where foo.h was already in use for client-side headers.
SDs may be detached during event processing (e.g. if a passive grab
activates). In this case, the event must not be processed through the master
device.
Reported-by: Thomas Jaeger
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Copying all classes into the master device has drawbacks for hybrid devices
(devices that are both mice and keyboards). If such a device posts an event,
it's key classes are moved into the VCP. The key event itself is unaffected
by keyboard grabs and the like.
Partial class copying copies depending on the event and copies the classes
into the right master device (i.e. the VCK for key events, the VCP for
pointer events).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's no need for internal events to be a struct with a single nested
union, we might as well make the union itself the InternalEvent.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
isMaster is not enough as long as we differ between master pointers and
keyboard. With flexible device classes, the usual checks for whether a
master device is a pointer (currently check for ->button, ->valuators or
->key) do not work as an SD may post an event through a master and mess this
check up.
Example, a device with valuators but no buttons would remove the button
class from the VCP and thus result in the
IsPointerDevice(inputInfo.pointer) == FALSE.
This will become worse in the future when new device classes are introduced
that aren't provided in the current system (e.g. a switch class).
This patch replaces isMaster with "type", one of SLAVE, MASTER_POINTER and
MASTER_KEYBOARD. All checks for dev->isMaster are replaced with an
IsMaster(dev).
dev->u.lastSlave was not signal safe since it was accessed by the DIX and
during signal handling.
Replaced with:
'dev->last.slave' for the signal handler's lastSlave (used to generate
DeviceChangedEvents), .
'dev->u.lastSlave' for the DIX lastSlave (currently only used in
change_modmap)
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
mieqProcessInputEvents doesn't process events from MDs anymore, so we don't
need to check for pDev->isMaster.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Best to FatalError if a wrong event comes in. At least that forces me to fix
it really quickly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
mieqProcessInputEvents() - pop an event off the EQ and pass it to
mieqProcessDeviceEvent() - process the event according to the MD/SD hierarchy.
This way, we can use mieqPDE() from Xtest, xkb, and others to post an event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't pass xEvent* and count through to processing, pass a single
InternalEvent.
Custom handlers are disabled for the time being. And for extra fun,
XKB's pointer motion emulation is disabled. But stick an error in there so
that we get reminded should we forget about it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Before dropping down into the DIX, convert back into XI events. This is a
temporary solution only, until the DIX is capable of handling InternalEvents
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This gets rid of the nevents parameter, InternalEvents are always a single
item per event. Also remove the special DeviceValuator handling in both
enqueueing and dequeueing.
Custom callback handlers are now broken until fixed.
For bisectability, we copy the InternalEvent back into the XI required during
POE and friends. Consider this a temporary solution.
Note: Because of misc linker bonghits, Xvfb won't link in this revision.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
After copying the master event, flip the detail field to the mapped button of
the SD, not the physical button. This way if the SD has a mapping 1:3 and the
MD has a mapping of 3:4, a press on button 1 on the SD results in a core event
on button 4.
X.Org Bug 19282 <http://bugs.freedesktop.org/show_bug.cgi?id=19282>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is more of a hack around the problem. This is something that will need to be addressed in a
more structured manner with the multi threaded input efforts.
(cherry picked from commit 3c596c061e)
A grep on xorg/* revealed there's no consumer of this define.
Quote Alan Coopersmith:
"The consumer was in past versions of the headers now located
in proto/x11proto - for instance, in X11R6.0's xc/include/Xproto.h,
all the event definitions were only available if NEED_EVENTS were
defined, and all the reply definitions required NEED_REPLIES.
Looks like Xproto.h dropped them by X11R6.3, which didn't have
the #ifdef's anymore, so these are truly ancient now."
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Alloc an EventList once and then re-use instead of allocing a new event each
time we need a master event.
There's a trick included: because all the event processing handlers only take
an xEvent, init a size 1 EventList and squash the events into this one.
Events that have count > 1 must be squished into an xEvent array anyway before
passing into the event handlers, so we don't lose anything here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Follow-up to 9ce995373e. This re-enables cursor rendering if the MD is
controlled through software (e.g. synergy).
Reported by John Tapsell: "I use Xorg with no mouse attached, but use synergy
to control the mouse. The commit means that I no longer have a visible mouse
cursor. The mouse cursor is still 'there' in terms that I can click buttons
etc with it, but it's just not visible."
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Save in a few special cases, _X_EXPORT should not be used in C source
files. Instead, it should be used in headers, and the proper C source
include that header. Some special cases are symbols that need to be
shared between modules, but not expected to be used by external drivers,
and symbols that are accessible via LoaderSymbol/dlopen.
This patch also adds conditionally some new sdk header files, depending
on extensions enabled. These files were added to match pattern for
other extensions/modules, that is, have the headers "deciding" symbol
visibility in the sdk. These headers are:
o Xext/panoramiXsrv.h, Xext/panoramiX.h
o fbpict.h (unconditionally)
o vidmodeproc.h
o mioverlay.h (unconditionally, used only by xaa)
o xfixes.h (unconditionally, symbols required by dri2)
LoaderSymbol and similar functions now don't have different prototypes,
in loaderProcs.h and xf86Module.h, so that both headers can be included,
without the need of defining IN_LOADER.
xf86NewInputDevice() device prototype readded to xf86Xinput.h, but
not exported (and with a comment about it).
This is the biggest "visibility" patch. Instead of doing a "export"
symbol on demand, export everything in the sdk, so that if some module
fails due to an unresolved symbol, it is because it is using a symbol
not in the sdk.
Most exported symbols shouldn't really be made visible, neither
advertised in the sdk, as they are only used by a single shared object.
Symbols in the sdk (or referenced in sdk macros), but not defined
anywhere include:
XkbBuildCoreState()
XkbInitialMap
XkbXIUnsupported
XkbCheckActionVMods()
XkbSendCompatNotify()
XkbDDXFakePointerButton()
XkbDDXApplyConfig()
_XkbStrCaseCmp()
_XkbErrMessages[]
_XkbErrCode
_XkbErrLocation
_XkbErrData
XkbAccessXDetailText()
XkbNKNDetailMaskText()
XkbLookupGroupAndLevel()
XkbInitAtoms()
XkbGetOrderedDrawables()
XkbFreeOrderedDrawables()
XkbConvertXkbComponents()
XkbWriteXKBSemantics()
XkbWriteXKBLayout()
XkbWriteXKBKeymap()
XkbWriteXKBFile()
XkbWriteCFile()
XkbWriteXKMFile()
XkbWriteToServer()
XkbMergeFile()
XkmFindTOCEntry()
XkmReadFileSection()
XkmReadFileSectionName()
InitExtInput()
xf86CheckButton()
xf86SwitchCoreDevice()
RamDacSetGamma()
RamDacRestoreDACValues()
xf86Bpp
xf86ConfigPix24
xf86MouseCflags[]
xf86SupportedMouseTypes[]
xf86NumMouseTypes
xf86ChangeBusIndex()
xf86EntityEnter()
xf86EntityLeave()
xf86WrapperInit()
xf86RingBell()
xf86findOptionBoolean()
xf86debugListOptions()
LoadSubModuleLocal()
LoaderSymbolLocal()
getInt10Rec()
xf86CurrentScreen
xf86ReallocatePciResources()
xf86NewSerialNumber()
xf86RandRSetInitialMode()
fbCompositeSolidMask_nx1xn
fbCompositeSolidMask_nx8888x0565C
fbCompositeSolidMask_nx8888x8888C
fbCompositeSolidMask_nx8x0565
fbCompositeSolidMask_nx8x0888
fbCompositeSolidMask_nx8x8888
fbCompositeSrc_0565x0565
fbCompositeSrc_8888x0565
fbCompositeSrc_8888x0888
fbCompositeSrc_8888x8888
fbCompositeSrcAdd_1000x1000
fbCompositeSrcAdd_8000x8000
fbCompositeSrcAdd_8888x8888
fbGeneration
fbIn
fbOver
fbOver24
fbOverlayGeneration
fbRasterizeEdges
fbRestoreAreas
fbSaveAreas
composeFunctions
VBEBuildVbeModeList()
VBECalcVbeModeIndex()
TIramdac3030CalculateMNPForClock()
shadowBufPtr
shadowFindBuf()
miRRGetScreenInfo()
RRSetScreenConfig()
RRModePruneUnused()
PixmanImageFromPicture()
extern int miPointerGetMotionEvents()
miClipPicture()
miRasterizeTriangle()
fbPush1toN()
fbInitializeBackingStore()
ddxBeforeReset()
SetupSprite()
InitSprite()
DGADeliverEvent()
SPECIAL CASES
o defined as _X_INTERNAL
xf86NewInputDevice()
o defined as static
fbGCPrivateKey
fbOverlayScreenPrivateKey
fbScreenPrivateKey
fbWinPrivateKey
o defined in libXfont.so, but declared in xorg/dixfont.h
GetGlyphs()
QueryGlyphExtents()
QueryTextExtents()
ParseGlyphCachingMode()
InitGlyphCaching()
SetGlyphCachingMode()
This way we on't need to hold the mutex during the dixSaveScreens() call.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Tiago Vignatti <vignatti@c3sl.ufpr.br>
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Copy the EventRec's information into local variables before processing them,
this should make it safer for upcoming threading and also makes it easier to
read.
Simplify the event allocation code from the abyss it was before.
This also fixes a potential bug where a custom handler could scramble the
event before the same -now scrambled- event was then passed through the
master's custom event handler.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
When MouseKeys are activated, keyboard devices may generate fake mouse button
events through XKB. Let's get then running through the appropriate paths, i.e.
as XI events on the correct device.
To make matters more fun, ProcessOtherEvents drops events if the DIX device
state cannot be updated accordingly, i.e. all button events from keyboard
devices.
Hence we need to get the paired MD for the device in XkbDDXFakeDeviceButton,
and post the event through the paired MD (usually the VCP).
Removes now-unused ddxFakeBtn.c.
Note: this patch only half-arsedly fixed button events, motion events are a
more complicated matter.
Since we're probably stuck down in a driver somewhere, let's at least
try to point out where. This will need to be rethought when the input
thread work lands though.
When a new device is added, calculate the event size needed if a DCCE event is
sent and set the EQ's event size to this minimum. This avoids reallocs when a
event is sent (which may happen during a SIGIO).
Add Prox events to the if-clauses with the other events
that are usually sent from the input devices.
Ensure that the event deliverers won't try to deliver
events of type '0' (some extended events doesn't have
an equivalent core-type)
Small modification by Peter Hutterer.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
Initialise num_events to 1, so we always send a proximity event, and then
optionally valuator events. Also make sure mieq can deal with valuator
events sent after proximity events.
If a slave device is attached to a master device, then we need to send a
mapping notify to the client.
Mapping notify needs to be sent if
- different slave device but on same master
- different master
This gives you funny behaviour with the ClientPointer. When a
MappingNotify is sent to the client, the client usually responds with a
GetKeyboardMapping. This will retrieve the ClientPointer's keyboard mapping,
regardless of which keyboard sent the last mapping notify request. So
depending on the CP setting, your keyboard may change layout in each app...
Each time a different slave device sends through a master, an
DeviceClassesChangedEvent is enqueued. When this event is processed, all
classes of the matching master device are changed, and the event is sent to
the clients.
Next time the master is queried, it thus shows the evclasses of the last slave
device. The original classes are stored in the devPrivates.
TODO: if all slave devices are removed, the master's original classes need to
be restored.
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.
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
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.
Add RawDeviceEvent (pointers only for now).
This commit changes the event queue to use EventLists instead of xEvent
arrays. Only EQ is affected, event delivery still uses xEvent* (look for
comment in mieqProcessInputEvent).
RawDeviceEvents deliver driver information to the client, without clipping or
acceleration.
Requires moving the spriteTrace into the DeviceIntRec and adjusting a few
functions to take in device argument, most notably XYToWindow().
Cursor rendering on the second screen is busted.
bugfix: uninitialized pPointer in miPointerGetPosition ifndef MPX
adding DeviceIntPtr parameter to ScreenRec's cursor functions.
cleanup of miPointer code to use same scheme in each function
dix: MPHasCursor() function determines checking whether to invoke
cursor rendering.
animcur: adding DeviceIntPtr parameter to cursor functions but animcur relies
on the core pointer right now.
xfixes: adding DeviceIntPtr parameter to cursor functions but xfixes relies on
the core pointer right now.
rac: adding DeviceIntPtr parameter to cursor functions but RAC relies on
the core pointer right now.
ramdac: adding DeviceIntPtr parameter to cursor functions but ramdac relies on
the core pointer right now.
added SpriteRecs for MPX devices
changed sprite dependency and added MPX functionality to parts
of events.c (ConfineToShape, PostNewCursor, XineramaCheckMotion,
CheckMotion, XineramaChangeToCursor, ChangeToCursor, CheckPhysLimits,
PointerConfinedToScreen)
added DeviceIntRec param to GetSpritePosition(). This required some
minor changes in ddx, xtest, xkb and xfixes.
mi: changed miPointer to pointer instead of static struct.
added miCursorInfoRec to contain info of the MPX cursors.
calling miUpdatePointerSprite() from event queue for MPX devices.
adding device-specific processing to miPointer*() functions.
dix: Call to SetCursorPosition in CheckMotion() temporarily disabled.
xfree86/common: call to miPointerUpdateSprite() disabled, is done from the EQ
NOTE: This build will not display cursor images.
BUG: The second mouse does to take correct x coordinates.
mieq: avoid merging events from different devices in mieqEnqueue()
xfree86/common
isMPdev field used from xf86ActivateDevice(), xf86PostMotionEvent()
and xf86PostButtonEvent()
Move the keymap copying to event processing time (in
ProcessInputEvents), instead of being at event enqueuing time.
Break SetCore{Pointer,Keyboard} out into separate functions.
Change mieqEnqueue to take a device pointer, that asks for the
_original_ device associated with this event.
Update mipointer API to take a device argument to (almost) all functions,
and split miPointerAbsoluteCursor into a couple of separate functions.
Remove miPointerAbsoluteCursor call from mieq, as we now deal with it in
GetPointerEvents.
Make miPointerSetPosition (successor of miPointerAbsoluteCursor) take
pointers to x and y, so it can return the clipped values.
Modify callers of miPointer*() functions to generally use the new
functions.
This should fix things with multi-head setups.
Jeremy Huddleston
Pierre Willenbrock
Peter Hutterer
David Miller
Peter Hutterer
Paulo Cesar Pereira de Andrade
Adam Jackson
Tiago Vignatti
Peter Hutterer
Magnus Vigerlöf
Bartosz Fabianowski
Eamon Walsh
Michel Dänzer
Paulo Ricardo Zanoni
Daniel Stone
Stefan Huehner
Fredrik Höglund