Consider all attached output providers when looking for changed outputs and
crtcs.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 85ae44f07f)
Send RRResourceChangeNotify event when provider, output or crtc was created or
destroyed. I.e. when the list of resources returned by RRGetScreenResources and
RRGetProviders changes.
[airlied: move structure member to avoid ABI breakage]
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit a9ca93dcf9)
Send RRProviderChangeNotify event when a provider becomes output source or
offload sink.
[airlied: unbreak the ABI for 1.14 backport.]
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 4b39ea8a91)
When we disconnect an output/offload slave set the changed bits,
so a later TellChanged can do something.
Then when we remove a GPU slave device, sent change notification
to the protocol screen.
This allows hot unplugged USB devices to disappear in clients.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 9d26e8eaf5)
We don't want to know about changes on the non-protocol screen,
we will fix up setchanged to make sure non-protocol screens update
the protocol screens when they have a change.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit e233bda3e7)
When SetChanged is called we now modify the main protocol screen,
not the the gpu screen. Since changed stuff should work at the protocol level.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit b3f70f38ed)
Introduce a wrapper interface so we can fix things up for multi-gpu
situations later.
This just introduces the API for now.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit f9c8248b83)
Commit 8f4640bdb9 fixed a bit of a
chicken-and-egg problem by detaching GPU screens when their providers
are destroyed, which happens before CloseScreen is called. However,
this created a new problem: the GPU screen tears down its RandR crtc
objects during CloseScreen and if one of them is active, it tries to
detach the scanout pixmap then. This crashes because
RRCrtcDetachScanoutPixmap tries to get the master screen's screen
pixmap, but crtc->pScreen->current_master is already NULL at that
point.
It doesn't make sense for an unbound GPU screen to still be scanning
out its former master screen's pixmap, so detach them first when the
provider is destroyed.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit bdd1e22cbd)
As of server 1.13, systems with DRM and Udev will have BUS_PLATFORM as
their primary bus type. However, drivers not implementing a
platformProbe function will still create entities of type BUS_PCI. We
need to account for this when checking for the primary entity.
Signed-off-by: Connor Behan <connor.behan@gmail.com>
Acked-by: Tormod Volden <debian.tormod@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Consider all attached output providers when looking for changed outputs and
crtcs.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Send RRResourceChangeNotify event when provider, output or crtc was created or
destroyed. I.e. when the list of resources returned by RRGetScreenResources and
RRGetProviders changes.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Send RRProviderChangeNotify event when a provider becomes output source or
offload sink.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
When we disconnect an output/offload slave set the changed bits,
so a later TellChanged can do something.
Then when we remove a GPU slave device, sent change notification
to the protocol screen.
This allows hot unplugged USB devices to disappear in clients.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We don't want to know about changes on the non-protocol screen,
we will fix up setchanged to make sure non-protocol screens update
the protocol screens when they have a change.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When SetChanged is called we now modify the main protocol screen,
not the the gpu screen. Since changed stuff should work at the protocol level.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Introduce a wrapper interface so we can fix things up for multi-gpu
situations later.
This just introduces the API for now.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit 8f4640bdb9 fixed a bit of a
chicken-and-egg problem by detaching GPU screens when their providers
are destroyed, which happens before CloseScreen is called. However,
this created a new problem: the GPU screen tears down its RandR crtc
objects during CloseScreen and if one of them is active, it tries to
detach the scanout pixmap then. This crashes because
RRCrtcDetachScanoutPixmap tries to get the master screen's screen
pixmap, but crtc->pScreen->current_master is already NULL at that
point.
It doesn't make sense for an unbound GPU screen to still be scanning
out its former master screen's pixmap, so detach them first when the
provider is destroyed.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Now that the brackets are always the nearest change points (regardless of
transition) we need to update the counters whenever we check for any updates.
Otherwise we end up with a situation where counter->value is out of date and
an alarm doesn't trigger because we're still using the value from last time
something actually triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 2523a445a0)
The current code sets bracket_greater to the first trigger after the current
value, and bracket_less to the last trigger before the current value.
For example, the idle timer with three negative and three positive transitions
would set this:
nt1 nt2 nt3
|--------|------|--|------- idle --|---|--|-----> t
pt1 pt2 pt3
bracket_less == nt2
bracket_greater == pt2
This is an optimization so we can skip code paths in the block/wakeup handlers
if the current value doesn't meet any of the trigger requirements. Those
handlers largely do a
if (bracket_less is less than current value &&
bracket_greater is greater than current value)
return, nothing to do
However, unless the bracket values are updated at the correct time, the
following may happen:
nt
|--------------|---------- idle ------|--------> t
pt
In this case, neither bracket is set, we're past the pos transition and not
yet at the neg transition. idle may now go past nt, but the brackets are not
updated. If idle is then reset to 0, no alarm is triggered for nt. Likewise,
idle may now go past pt and no alarm is triggered.
Changing an alarm or triggering an alarm will re-calculate the brackets, so
this bug is somewhat random. If any other client triggers an alarm when the
brackets are wrongly NULL, the recalculation will set them this bug may not
appear.
This patch changes the behavior, so that the brackets are always the nearest
positive or negative transitions to the current counter value. In the example
above, nt will trigger a wakeup and a re-calculation of the brackets, so that
going past it in the negative direction will then cause the proper alarm
triggers.
Or, in Keith's words:
Timer currently past a positive trigger
No bracket values, because no trigger in range
Timer moves backwards before the positive trigger
Brackets not reset, even though there is now a trigger in range
Timer moves forward past the positive trigger
Trigger doesn't fire because brackets not set
Setting the LT bracket in this case will cause everything to get
re-evaluated when the sync value moves backwards before the trigger
value.
X.Org Bug 59644 <http://bugs.freedesktop.org/show_bug.cgi?id=59644>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit e57ec99b03)
The time between the idle reset and the IdleTimeWakeupHandler to be called is
indeterminate. Clients with an PositiveTransition or NegativeTransition alarm
on a low threshold may miss an alarm.
Work around this by keeping a reset flag for each device. When the
WakeupHandler triggers and the reset flag is set, we force a re-calculation of
everything and pretend the current idle time is zero. Immediately after is the
next calculation with the real idle time.
Relatively reproducible test case: Set up a XSyncNegativeTransition alarm for
a threshold of 1 ms. May trigger, may not.
X.Org Bug 70476 <http://bugs.freedesktop.org/show_bug.cgi?id=70476>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 06b87aa528)
And now that we have the accessors, localize it. No functional changes, just
preparing for a future change.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit efc1035ca9)
The main idletime counter has an initialized deviceid, might as well be
supplying it properly. Without this, we'd only ever check the XIAllDevices
counter, so the wait would never be adjusted for the device-specific triggers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit b7c9bd9cf2)
Both ServertimeBracketValues and IdleTimeBracketValues copy the value into
there SysCounter privates. Call it for a NULL set as well, so we don't end up
with stale pointers and we can remove the block/wakeup handlers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 2efe49c102)
No functional changes, just merges a > and == condition into a >= condition.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 5c7cfd4c69)
Use the grabtype to determine which type of event to send - all other events
are pointless and may result in erroneous events being delivered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 7cf1b595c8)
For an active grab, grab->eventMask can be either the core or the XI1 mask.
With the overlap of event filters, calling DeliverOneGrabbedEvent(XI1) for a
ProximityOut event will trigger if the client has selected for enter events -
the filter is the same for both.
Thus, we end up delivering a proximity event to a client not expecting one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 78944d62ff)
If a client calls XAllowEvents(SyncPointer) it expects events as normal until
the next button press or release event - that freezes the device. An e.g.
proximity event must thus not freeze the pointer.
As per the spec, only button and key events may do so, so narrow it to these
cases.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit be6ea80b79)
If we have a client which has registered for a DeviceButton grab
be sure to pass this to CheckDeviceGrabAndHintWindow(). Since the
order of clients is arbitrary there is no guarantee that the last
client in the list is the one that belongs to this class.
Signed-off-by: Egbert Eich <eich@freedesktop.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 05ea6307fa)
XIAllowEvents changed length in XI 2.2 (for the touchid). A bug in libXi
causes libXi to always use the new request length if the server supports
2.2, regardless of the client's XIQueryVersion request.
The server takes the client's XIQueryVersion request into account though,
resulting in a BadLength error if a 2.[0,1] client calls XIAllowEvents on a
XI 2.2+ server.
Can't fix this in libXi, so work around this in the server.
X.Org Bug 68554 <http://bugs.freedesktop.org/show_bug.cgi?id=68554>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 94d4e29aed)
if the grab type isn't XI2, grab->xi2mask is random. That random data may
have the enter/leave mask set, leading to events sent to the client that the
client can't handler.
Source of these errors:
_xgeWireToEvent: Unknown extension 131, this should never happen.
Simplest reproducer:
Start Xephyr, press button inside window, move out. As the pointer leaves
the Xephyr window, the errors appear.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 82939e0239)
pop without push restores the commandline options. The proper way is to
push, then ignore, then pop.
And while we're at it, change the pop argument to a comment - pop ignores
the argument, but be proper about it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit d803f296c6)
Code to recognize these in extension enable/disable options was wrapped
in #ifdef XorgLoader, but that's not defined when building miinitext.c
since the great module merge of 1.13. Change to an #ifdef that is defined.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Robert Hooker <robert.hooker@canonical.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Save a pointer to the passed in closure structure before copying it
and overwriting the *c pointer to point to our copy instead of the
original. If we hit an error, once we free(c), reset c to point to
the original structure before jumping to the cleanup code that
references *c.
Since one of the errors being checked for is whether the server was
able to malloc(c->nChars * itemSize), the client can potentially pass
a number of characters chosen to cause the malloc to fail and the
error path to be taken, resulting in the read from freed memory.
Since the memory is accessed almost immediately afterwards, and the
X server is mostly single threaded, the odds of the free memory having
invalid contents are low with most malloc implementations when not using
memory debugging features, but some allocators will definitely overwrite
the memory there, leading to a likely crash.
Reported-by: Pedro Ribeiro <pedrib@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Replace hardcoded SVR4 || linux || CSRG_BASED with an autoconf check and
the _POSIX_SAVED_IDS macro.
Suggested-by: Mark Kettenis <mark.kettenis@xs4all.nl>
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit c218ba8423)
Missing _XSERVER64 define caused inconsistent sizeof(XID) between the
test and hashtable code, leading to test failures on 64bit big endian
archs like s390x or ppc64.
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 930c6ff15d)
I'm getting a error building xorg-server-1.14.1.902 with thelatest snapshot
of gcc-4.8:
input.c:225:43: error: array subscript is above array bounds
[-Werror=array-bounds]
This is because kdNumInputFds can become equal to KD_MAX_INPUT_FDS in
KdRegisterFd(). This means that in KdUnregisterFd(), kdInputFds[j + 1] can
be beyond the end of the array.
Signed-off-by: Chris Clayton <chris2553@googlemail.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The old code was broken and allowed setting client version >= XIVersion,
this was fixed in the previous patch, but updating the value for XIVersion
broke the tests, so fix the tests too.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit b6e5c4669e)
Do not allow setting client version to an arbitrary value >= XIVersion.
Fixes a test error with test/xi2/protocol-xiqueryversion.c, introduced by
commit 4360514d1c "Xi: Allow clients to ask for 2.3 and then 2.2 without failing"
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 500e844a24)
