Because some EnterVT code needs to remove it self from the
call chain, we need to fix all of the wrappers to correctly
unwrap/rewrap during the call chain. This is a follow-on to the fix
for bug 27114 in commit 68a9ee8370.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Jesse Barnes <jesse.barnes@intel.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
If a pixmap header is modified or the drawable serial changes, some
aspects of the drawable are likely to have changed so we should
re-allocate the corresponding DRI2 drawable in that case. This is one
way of catching when the root window pixmap changes through xrandr.
Fixes bug https://bugs.freedesktop.org/show_bug.cgi?id=28365.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
We should update the serial number even if we just change a single field.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Same as the matching key functions. Buttons, like keys, can have two states
for down/up - one posted, one processed. Posted is set during event
generation (usually in the signal handler). Processed is set during event
processing when the event queue is emptied and events are being delivered to
the client.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Having miPointerMove and miPointerMoved is confusing, especially since both
do the same thing bar the event delivery. Also, miPointerMove calls
miPointerMoved which indicates some confusion in the temporal alignment of
cause and effect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Support for the blend mode operators was added in
0ce42adbf4
and the requirement was bumped but when things were split off into
include/protocol-versions.h it defined it to 10. render uses
the lower of the client and server advertised versions so it's not
using the new blend mode operators.
Signed-off-by: Robert Hooker <sarvatt@ubuntu.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
miDbeInit pre-allocates space in each DBE window private private for a
MiDbeWindowPrivPrivRec. miDbeAllocBackBufferName used the
pre-allocated space correctly (simply fetching it instead of
allocating a new piece of memory). However, it then called
dixSetPrivate anyways, which isn't necessary, and (in the new
dixPrivate world) causes an assert failure.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Magnus Kessler <Magnus.Kessler@gmx.net>
Reviewed-by: Magnus Kessler <Magnus.Kessler@gmx.net>
MiDbeScreenPrivPrivRec is not used in the server. Remove it, along
with the MI_DBE_SCREEN_PRIV_PRIV macro that tried to use it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Magnus.Kessler <Magnus.Kessler@gmx.net>
Fix for OpenSolaris bug 6949755: Mouse Keys are ununusable
and possibly https://bugs.freedesktop.org/show_bug.cgi?id=24856
Ensures waitForUpdate is False before calling SetCursorPosition.
Normally waitForUpdate is False when SilkenMouse is active, True
when it's not. When it's True, the mouse cursor position on
screen is not updated immediately.
This is more critical on Solaris, since we disabled SigIO, thus in turn
disable SilkenMouse, due to the SSE2 vs. signal handler issues described in
Sun bugs 6849925, 6859428, and 6879897.
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>
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 this privates.h is included in C++ builds, the compiler
complains about implicitly casting void* to void**. This small
patch fixes that up.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
If a button release event is posted for the MD pointer, post a release event
through the matching XTEST device. This way, a client who posts a button
press through the XTEST extension cannot inadvertedly lock the button.
This behaviour is required for historical reasons, until server 1.7 the core
pointer would release a button press on physical events, regardless of the
XTEST state. Clients seem to rely on this behaviour, causing seemingly stuck
grabs.
The merged behaviour is kept for multiple keyboard PointerKey events, if two
physical keyboards hold the button down as a result of PointerKey actions,
the button is not released until the last keyboard releases the button.
X.Org Bug 28808 <http://bugs.freedesktop.org/show_bug.cgi?id=28808>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Although vendor and board naming are used to create the configure file, the
server doesn't actually use it when fetching such file and probing devices.
Reported-by: Richard Barnette <jrbarnette@chromium.org>
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
X server suffers in startup time when relying on the pciaccess's linear search
to fetch vendor and video device name from PCI ID file (when existent). Such
names are only used to write the log, which may be superfluous. This
information often is provided by the drivers or likewise users can get the it
using external tools like lspci or scanpci.
This patch remove the references of those functions from X start up.
Reported-by: Richard Barnette <jrbarnette@chromium.org>
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: James Cloos <cloos@jhcloos.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This patch replicates the behaviour for button events. Only generate a
PointerKeys motion event on the master device, not on the slave device.
Fixes the current issue of PointerKey motion events generating key events as
well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Problem:
lockedPtrButtons keeps the state of the buttons locked by a PointerKeys button
press. Unconditionally clearing the bits may cause stuck buttons in this
sequence of events:
1. type Shift + NumLock to enable PointerKeys
2. type 0/Ins on keypad to emulate Button 1 press
→ button1 press event to client
3. press and release button 1 on physical mouse
→ button1 release event to client
Button 1 on the MD is now stuck and cannot be released.
Cause:
XKB PointerKeys button events are posted through the XTEST pointer device.
Once a press is generated, the XTEST device's button is down. The DIX merges
the button state of all attached SDs, hence the MD will have a button down
while the XTEST device has a button down.
PointerKey button events are only generated on the master device to avoid
duplicate events (see XkbFakeDeviceButton()). If the MD has the
lockedPtrButtons bit cleared by a release event on a physical device, no
such event is generated when a keyboard device triggers the PointerKey
ButtonRelease trigger. Since the event - if generated - is posted through
the XTEST pointer device, lack of a generated ButtonRelease event on the
XTEST pointer device means the button is never released, resulting in the
stuck button observed above.
Solution:
This patch merges the MD's lockedPtrButtons with the one of all attached
slave devices on release events. Thus, as long as one attached keyboard has
a lockedPtrButtons bit set, this bit is kept in the MD. Once a PointerKey
button is released on all keyboards, the matching release event is emulated
from the MD through the XTEST pointer device, thus also releasing the button
in the DIX.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Looks like nothing broke from removing the hardcoded CoreProcessPointerEvent
call. Whoop. Di. Doo.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Initializing the dev privates code after allocating the server client
dev privates would cause the memory leak check to fire at server
startup or reset.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Daniel Stone <daniel@fooishbar.org>
The allocated bus id string was not being freed.
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
When the "Rotate" option isn't specified allow the driver to specify
the initial rotation mode. This way the driver can choose to retain
the same settings that were used by software that was used prior to
starting X.
Signed-off-by: Ville Syrjälä <ville.syrjala@nokia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Problem:
lockedPtrButtons keeps the state of the buttons locked by a PointerKeys button
press. Unconditionally clearing the bits may cause stuck buttons in this
sequence of events:
1. type Shift + NumLock to enable PointerKeys
2. type 0/Ins on keypad to emulate Button 1 press
→ button1 press event to client
3. press and release button 1 on physical mouse
→ button1 release event to client
Button 1 on the MD is now stuck and cannot be released.
Cause:
XKB PointerKeys button events are posted through the XTEST pointer device.
Once a press is generated, the XTEST device's button is down. The DIX merges
the button state of all attached SDs, hence the MD will have a button down
while the XTEST device has a button down.
PointerKey button events are only generated on the master device to avoid
duplicate events (see XkbFakeDeviceButton()). If the MD has the
lockedPtrButtons bit cleared by a release event on a physical device, no
such event is generated when a keyboard device triggers the PointerKey
ButtonRelease trigger. Since the event - if generated - is posted through
the XTEST pointer device, lack of a generated ButtonRelease event on the
XTEST pointer device means the button is never released, resulting in the
stuck button observed above.
Solution:
This patch merges the MD's lockedPtrButtons with the one of all attached
slave devices on release events. Thus, as long as one attached keyboard has
a lockedPtrButtons bit set, this bit is kept in the MD. Once a PointerKey
button is released on all keyboards, the matching release event is emulated
from the MD through the XTEST pointer device, thus also releasing the button
in the DIX.
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>
When ResetCurrentRequest is called, or IgnoreClient is called when a
client has input pending, IgnoredClientsWithInput will be set. However,
a subsequent IgnoreClient request will clear the client fd from that fd
set, potentially causing the client to hang.
So add an Ignore/Attend count, and only apply the ignore logic on the
first ignore and the attend logic on the last attend. This is
consistent with the comments for these functions; callers must pair
them.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=27035.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Behaviour of earlier X servers was to deliver the ButtonPress event
unconditionally, regardless of the actual event mask being set. Thus, a
GrabButton event will always deliver the button press event, a GrabKey
always the key press event, etc. Same goes for XI and XI2.
Reproducible with a simple client requesting a button grab in the form of:
XGrabButton(dpy, AnyButton, AnyModifier, win, True, ButtonReleaseMask,
GrabModeAsync, GrabModeAsync, None, None);
On servers before MPX/XI2, the client will receive a button press and
release event. On current servers, the client receives only the release.
Clients that expect the press event to be delivered unconditionally may
leave the user with a stuck grab.
XTS test results for XGrabButton are identical with and without this patch.
This reverts commit 48585bd1e3.
Conflicts:
dix/events.c
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>
Behaviour of earlier X servers was to deliver the ButtonPress event
unconditionally, regardless of the actual event mask being set. This is
documented in the protocol:
"This request establishes a passive grab. In the future, the pointer is
actively grabbed as described in GrabPointer, the last-pointer-grab time is
set to the time at which the button was pressed (as transmitted in the
ButtonPress event), and the ButtonPress event is reported if all of the
following conditions are true:
<list of conditions, event mask is not one of them>"
Thus, a GrabButton event will always deliver the button press event, a
GrabKey always the key press event, etc. Same goes for XI and XI2.
Reproducible with a simple client requesting a button grab in the form of:
XGrabButton(dpy, AnyButton, AnyModifier, win, True, ButtonReleaseMask,
GrabModeAsync, GrabModeAsync, None, None);
On servers before MPX/XI2, the client will receive a button press and
release event. On current servers, the client receives only the release.
Clients that expect the press event to be delivered unconditionally.
XTS Xlib13 XGrabButton 5/39 now passes.
This reverts commit 48585bd1e3.
Effectively reverts commit 1c612acca8 as well,
the code introduced with 1c612 is not needed anymore.
Conflicts:
dix/events.c
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
It's already defined inside REQUIRED_LIBS and all DDX are getting it already.
No semantical changes.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
X server doesn't need to understand fpe internals, so use
register_fpe_functions from libXfont.
It's required to get new version of libXfont, therefore adjust it to be passed
to autoconf.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Can't use next as a macro argument since we're accessing the .next field
of struct list.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This reverts commit 9120e58556.
Whoops, please revert this patch -- overlay is in use in nvidia drivers,
and it's too late in release cycle to remove it.
I feel really sorry that I kept this patch in my tree. I will submit
another one, removing only XAA overlay hooks which are not used at all.
Execute the following steps to reproduce the issue.
1. Run at least two recording clients simultaneously.
$ cnee --record --request-range 1-127 &
$ cnee --record --request-range 1-127 &
2. Kill the recording clients.
$ killall cnee
3. Give X server something to do so that the clients are closed.
$ xinput list
$ xinput list
As a result RecordUninstallHooks accesses NullClient, because
RecordAClientStateChange doesn't clean the recording clients up
properly.
Fix RecordUninstallHooks to fail locally on an assertion instead of
much later in privates code, if NullClient is still accessed because
of some other bug. Fix RecordAClientStateChange to iterate through all
contexts so that modifications of the iterated array during iteration
don't cause contexts to be skipped.
Signed-off-by: Rami Ylimäki <ext-rami.ylimaki@nokia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
ProcDRI2Dispatch uses LocalClient to determine if it's safe to respond
to a client that has made DRI2 requests which aren't sensible for
remote clients (anything but version). When the client has disappeared
mid-request stream (e.g. as a result of a kill -9, or a client-side
bug), LocalClient causes the X server to follow suit, as
((OsCommPtr)client->osPrivate)->trans_conn is NULL at this point.
The simple and obvious fix is to just return "not local" when
trans_conn is NULL, which fixes the crash I was seeing; however Keith
Packard pointed out that just checking trans_conn isn't enough;
quoting Keith:
"This looks almost right to me -- I reviewed the os code to see when
_XSERVTransClose is called (which is what frees the trans_conn data) and
found that every place which called that immediately set trans_conn to
NULL, except for the call in CloseDownFileDescriptor which is only
called from CloseDownConnection and which is immediately followed by
freeing the OsCommRec and setting client->osPrivate to NULL. So, I'd
suggest checking client->osPrivate in addition to the above check."
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The fixes for the composite reallocation failure, were freeing the oldpixmap
straight after reallocating the new one, however this led to some wierd
effects in e16 compositing, and I think in a few other places. This patch
moves the freeing of the pixmap into the post wrapped stage. I'm not sure if
we are actually better off breaking ABI and adding another callback from the
ConfigureWindow to composite to make sure the old pixmap is always freed,
but this should be satisfactory as we should always hit one of the freeing
paths or else its a bug in the DIX.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=28435
Reported-by: Andrew Randrianasulu <randrik@mail.ru>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>