The server was processing ET_RawMotion type when the cursor was wrapping to
another screen and getting wrong valuator values. This fix such issue
considering only ET_Motion, ET_KeyPress, ET_KeyRelease, ET_ButtonPress and
ET_ButtonRelease types when the cursor detects a new screen, keeping the
"normal" processing of device events.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is long overdue. The device events are InternalEvents now (and only one
at a time), diminishing the need for an EventList for the master event.
Furthermore, don't make masterEvent a static since this will interfere if
mieqProcessDeviceEvent is called from somewhere else (e.g. XKB actions).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
InternalEvents shouldn't be used anywhere outside the X server itself. Split
up into events.h for opaque typedefs for the events needed by various
headers and eventstr.h for the actual struct definitions.
eventstr.h must only be included by code that requires internal events and
is not part of the SDK.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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).
