Right now, Xephyr and others don't get to use XKB on the slave devices.
Which works given that no-one cares about SDs just yet but event processing
is different if the ProcessInputProc isn't wrapped properly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
From the documentation:
"This is mainly to allow a touch screen to be used with netscape and other
browsers which do strange things if the mouse moves between button down and
button up."
CLOSED - NOTOURBUG
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
PreInit returns a status code. Let's use that instead of having it report
Success in some cases but not set the XI86_CONFIGURED flag and thus signal
an init failure.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
These defines have been write-only for a while now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
RegisterPointerDevice() and RegisterKeyboardDevice() were already mapped to
RegisterOtherDevice() and obsolete.
RegisterOtherDevice() was called for all devices and the two assignments can
simply be moved into AddInputDevice(). Purge RegisterOtherDevice() and
pretend it never happened.
*lalalalala*
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
ActivateGrab and DeactivateGrab are set in AddInputDevice() already.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
No-one but the joystick driver uses it and that one should be using NIDR
instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
config_info is the only reliable indicator we have in the server for
duplicate devices (drivers can test for maj/min on fds as well). Don't set
this after the device has been initialized but assume it's important enough
to set during NIDR.
This makes the option "config_info" available to the drivers as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
The main change introduced in this patch is the removal of the
back-and-forth between DDX and the driver.
The DDX now allocates the InputInfoRec and fills it with default values. The
DDX processes common options (and module-specific default options, if
appropriate) before passing the initialised struct to the driver.
The driver may do module-specific initializations and return Success or an
error code in the case of a failure.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
A window with either dimension > 32767 can be positioned such that
coordinates > 32767 are visible on the screen. Attempts to draw to
those pixels will generate coordinates wrapped around to negative
values.
The optimized clipping macro, 'isClipped', in fbbits.h, computes
clipping in window space rather than screen space using int16 values,
and so it too has coordinates wrapped around to negative values and
hence ends up accepting the wrapped drawing coordinates.
Two possible fixes for this problem
1) Detect wrapped region coordinates and clip those to 32767.
2) Detect negative incoming coordinates and reject those
This patch takes the second approach as it is much shorter, simply
detecting when either X or Y incoming coordinate is negative, which
can never be 'within' any drawable.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
A simple hack to accommodate various EDID who have detailed modes that
exceed the EDID's max pixel clock. The pixel clock is only defined in
units of 10MHz and often appears as the maximum pixel code of the
detailed modes, rounded to the nearest 10MHz. Adjusting the max_clock to
include an extra 5MHz prevents the parser from rejecting the detailed
modes.
The kernel uses the same fuzz and by including it in X we can use the
same modes in X as for the console.
Fixes:
Bug 23833 - X uses different refresh rate to that set by kernel module
https://bugs.freedesktop.org/show_bug.cgi?id=23833
In the future, we will want to try harder to keep the KMS modes but at
the same time we need to apply the restrictions as specified by the
user's configuration, and need to fill in modes for fullscreen games on
fixed-mode panels.
Reported-and-tested-by: Fabio Pedretti <fabio.ped@libero.it>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
During a SwapBuffers request, we may end up querying an unknown drawable
outside of an active context, and so need to report this error prior to
attempting to dereference the NULL context.
Also fixes:
[Bug 29184] glXSwapBuffers with no GLX context crashes X.
https://bugs.freedesktop.org/show_bug.cgi?id=29184
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
GPE and friends modify the valuators array passed in. Which means any driver
using e.g. xf86PostButtonEventP(..., valuators) twice to emulate a button
click will provide garbage data on the second run.
This is currently affecting the wacom driver, xf86PostButtonEventP() with
valuators is required to have input events with device-specific axis values.
Passing the same valuators in twice, once with press, once with release,
will see the valuators modified in the first call and garbage submitted in
the next one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
From: Dave Airlie <airlied@linux.ie>
We were seeing a crash in the FreeAllResources codepath,
running valgrind revealed this,
==12536== Invalid read of size 4
==12536== at 0x810BCAB: DeliverPropertyEvent (rrproperty.c:33)
==12536== by 0x80958A4: TraverseTree (window.c:227)
==12536== by 0x809593E: WalkTree (window.c:255)
==12536== by 0x810BC66: RRDeliverPropertyEvent (rrproperty.c:53)
==12536== by 0x810BD5D: RRDeleteProperty.clone.0 (rrproperty.c:76)
==12536== by 0x810BD98: RRDeleteAllOutputProperties (rrproperty.c:88)
==12536== by 0x810A36E: RROutputDestroyResource (rroutput.c:407)
==12536== by 0x808DF4E: FreeClientResources (resource.c:859)
==12536== by 0x808E005: FreeAllResources (resource.c:876)
==12536== by 0x8062300: main (main.c:305)
==12536== Address 0x46ba8ac is 4 bytes inside a block of size 164 free'd
==12536== at 0x40057F6: free (vg_replace_malloc.c:325)
==12536== by 0x8087F1F: _dixFreeObjectWithPrivates (privates.c:357)
==12536== by 0x809832A: DeleteWindow (window.c:926)
==12536== by 0x808DF4E: FreeClientResources (resource.c:859)
==12536== by 0x808E005: FreeAllResources (resource.c:876)
==12536== by 0x8062300: main (main.c:305)
Its a use after free on the root window, since we have already deleted it
at this point. This patch checks if the window we are destroying is the root
window and resets the pointer to NULL if it is.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Tested-by: Dave Airlie <airlied@redhat.com>
We still have the issue with not raising the frontmost window for the case
when spaces is enabled, and the AppleSpacesSwitchOnActivate preference is
disabled.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
None of them do anything useful now that pointer acceleration is
entirely handled in the server. (Does not completely nuke yet,
since that would be an API/ABI break.)
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the parser sees the "keyboard" driver, it automatically (and
silently) replaces it with the constant string "kbd".
Everybody else uses malloc'd memory for the driver name, so input
device closure assumes it can use free.
Free val.str, so this crash doesn't turn into a memory leak. Whew.
Signed-off-by: Jesse Adkins <jesserayadkins@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
After copying the unused_classes into the device, reset the original
pointer. Otherwise we have two pointers pointing to the same field and both
get freed on device removal.
Some classes already have this behaviour since 51c8fd69.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
If the button we're about to fake isn't down (or up), don't fake a release
(or press) event for it. Behaviour is the same as before, this just saves
a few cycles.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
commit 1432785839
xkb: release XTEST pointer buttons on physical releases. (#28808)
revealed a bug with the XTEST/PointerKeys interaction.
Events resulting from PointerKeys are injected into the event processing
stream, not appended to the event queue. The events generated for the fake
button press include a DeviceChangedEvent (DCE), a raw button event and the
button event itself. The DCE causes the master to switch classes to the
attached XTEST pointer device.
Once the fake button is processed, normal event processing continues with
events in the EQ. The master still contains the XTEST classes, causing some
events to be dropped if e.g. the number of valuators of the event in the
queue exceeds the XTEST device's number of valuators.
Example: the EQ contains the following events, processed one-by-one, left to
right.
[DCE (dev)][Btn down][Btn up][Motion][Motion][...]
^ XkbFakeDeviceButton injects [DCE (XTEST)][Btn up]
Thus the event sequence processed looks like this:
[DCE (dev)][Btn down][Btn up][DCE (XTEST)][Btn up][Motion][Motion][...]
The first DCE causes the master to switch to the device. The button up event
injects a DCE to the XTEST device, causing the following Motion events to be
processed with the master still being on XTEST classes.
This patch post-fixes the injected event sequence with a DCE to restore the
classes of the original slave device, resulting in an event sequence like
this:
[DCE (dev)][Btn down][Btn up][DCE (XTEST)][Btn up][DCE (dev)][Motion][Motion]
Note that this is a simplified description. The event sequence injected by
the PointerKeys code is injected for the master device only and the matching
slave device that caused the injection has already finished processing on
the slave. Furthermore, the injection happens as part of the the XKB layer,
before the unwrapping of the processInputProc takes us into the DIX where
the DCE is actually handled.
Bug reproducible with a device that reports more than 2 valuators. Simply
cause button releases on the device and wait for a "too many valuators"
warning message.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
The callback data passed by reference to the hook was allocated on stack
within the scope of the case statement. The compiler is free to reuse
any of that stack space whilst making the function call so we may end up
passing garbage into the callback.
References:
Bug 18451 - Xorg server 1.5.2 SEGV during XFixesGetCursorImage()
https://bugs.freedesktop.org/show_bug.cgi?id=18451
v2: Drop the unrelated hunk that snuck in when ammending the commit
message.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Commit 9de0e31746 changed the signature
of __GLXScreen's createDrawable method.
Update the glxWinCreateDrawable() function in XWin's GLX provider
appropriately.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Tested-by: Colin Harrison <colin.harrison@virgin.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Recursive alpha maps (where one picture's alpha map is set to a
picture with an external alpha map) would be all fine and dandy,
except for the case where the client constructs a loop. Detecting this
case when setting the alpha map values would be difficult as any time
an alpha map is set, the server would have to check for the looping
case.
Instead, a far simpler fix is to simply disallow recursive alpha maps
in the rendering code, the Render spec is ambiguous in this area and
allows us to to ignore the recursive case.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
IsFramedWindow() is called from miPaintWindow() if the server has
been built with ROOTLESS defined, irrespective of if RootlessInit()
has ever been called, or not.
Add a check to IsFramedWindow() to check if rootlessWindowPrivateKey
has been registered (as a proxy for checking if the rootless extension
has been initialized) so we don't go on to try to use that key,
triggering an assert.
This bug exposes what appears to be a difference in opinion about
the rootless extension between XQuartz and XWin. XQuartz always
initializes the rootless extension, whereas XWin offers several modes
of operation, and the rootless extension is only used for one of them
That probably means that the all code under compile time guard for
ROOTLESS should be carefully checked that it doesn't also need to be
under a run-time guard
(I've reviewed the other ROOTLESS blocks in dix/events.c and
dix/window.c and they look ok -- keithp)
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When doing Xinerama, we'll dispatch font ops across all backend screens.
If using a font server (such that some operations can sleep), we'll put
the client to sleep once for each screen, but only wake up once, because
we're trying to keep track of the sleep count in _each_ screen's
closure.
Instead, just ask the core whether the client is already asleep.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The dtrace doc was recently added in commit
9c171d4aee
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Change the damage extension reporter to queue up events after we chain
to the wrapped functions. Damage events are typically sent out after
the rendering happens anyway, since we submit batch buffers from the
flush callback chain and then flush client io buffers. Compositing
managers relie on this order, and there is no way we could reliably
provide damage events to clients before the rendering happens anyway.
By queueing up the damage events before the rendering happens, there's
a risk that the client io buffer may overflow and send the damage
events to the client before the driver has even seen the rendering
request. Reporting damage events after the rendering fixes this
corner case and better corresponds with how we expect this to work.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
We were missing the callback in a couple of places. Drivers may use
the flush callback to submit batched up rendering before events (for
example, damage events) are sent out, to ensure that the rendering
has been queued when the client receives the event.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Mark argument to DDC_checksum as const too.
Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We were incorrectly NULLing out pDraw in __GLXDrawable instead of ours in
__GLXAquaDrawable. (we should refactor to eliminate this redundancy later)
This was causing http://xquartz.macosforge.org/trac/ticket/426
This was benign until commit f0006aa58f
The root cause of this change was fed7ccc481ad1caaa518cafe944c2327a5d0b6c65
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Mostly pulled together from posts to my blog and the docs posted
at http://people.freedesktop.org/~alanc/dtrace/ and converted to
DocBook.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Patrick E. Kane <pekane52@gmail.com>
Reflects API change made in commit 895f40792a during Xorg 1.8 development
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Patrick E. Kane <pekane52@gmail.com>
Bumps minimum xorg-macros requirement from 1.6 to 1.10
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Patrick E. Kane <pekane52@gmail.com>
Devices that are both pointers and keyboards are not affected by keyboard
changes as their master device is a master pointer, not a master keyboard.
Use GetMaster() instead to ensure devices that are attached to the paired
master pointer device will still be update.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
The current core enter/leave does not cater for device grabs during
enter/leave events. If a window W contains a pointer P1 and a client grabs a
pointer P2, this pointer will not generate enter/leave events inside this
window.
Hack around this by forcing grabbed devices to always send enter/leave
events.
X.Org Bug 27804 <http://bugs.freedesktop.org/show_bug.cgi?id=27804>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
If the native root window isn't resized as well, we will likely crash the
next time we draw to the root. On OS X, this can be seen by:
1) Put the display preferences in the menu bar and set X11's preferences so you
can access the menu bar in fullscreen mode
2) Set the resolution of your screen lower than normal.
3) Start X11 in fullscreen mode. The root window will cover the screen as
expected.
4) Use the menu bar to increase the resolution of the display. The root
window will now cover the old area and not the full screen, but
'xwininfo -root' will report the full width.
5) Run 'xsetroot -solid red', and we have the crash you mention above.
Leaving/entering fullscreen after #4 will fix the problem. This is because the
WINREC is erased when we leave fullscreen mode and it is recreated upon
re-entry:
RootlessUpdateRooted(FALSE)
RootlessDisableRoot(screenInfo.screens[0])
RootlessDestroyFrame (pRoot, winRec);
RootlessUpdateRooted(TRUE)
RootlessEnableRoot(screenInfo.screens[0])
RootlessEnsureFrame(screenInfo.screens[0]->pRoot)
creates a new WINREC...
Signed-off-by: Jan Hauffa <hauffa@in.tum.de>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Acked-By: Jon TURNEY <jon.turney@dronecode.org.uk>
Tested-by: Jeremy Huddleston <jeremyhu@apple.com>
