This makes the ptr accel api actually sensible from a driver
perspective, since it avoids superfluous device lookups.
Also, makes independent accel contexts possible.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Allows security modules to enforce what property contents can be set by
clients. Uses the new DixPostAccess bit to distinguish between the
existing call made during the lookup (with the old property data) and
this new call. Note that this only applies to writes, prepends, or
appends to existing properties; for new properties the existing
DixCreateAccess hook call may be used since it includes the new data.
Refer to the XACE-Spec document in xorg-docs, section "Property Access."
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
This will be used for follow-up checks after a client has written something,
for security modules that enforce a set of valid values a client can set.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
If the check fails, leave the device off the returned list of info
structures. Under XI2, this may cause inconsistent views of the device
topology after a change (for example, devices disappearing from view,
or showing as attached to a master that cannot be seen). More work is
needed to deal with topology changes and device relabeling.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Presumably, some intelligent, XI2-aware management app will be calling
XISetClientPointer on behalf of other clients; this check makes sure
the target client has permission on the device.
Requires changing the prototype to return status code instead of Bool.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
New access modes are being passed to the device access hook for XI2:
DixCreateAccess for creating a new master device;
DixAdd/RemoveAccess for attaching/removing slave devices to a master; and
DixListProp/GetProp/SetPropAccess for device properties.
Refer to the XACE-Spec document in xorg-docs, section "Device Access."
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
LookupClientResourceComplex is used by DRI1 code to find and free a DRI
drawable in a callback, however when the DRI code returns this->value
is now pointing at freed memory. It seemed easiest to store the value
to a temporary and return it afterwards.
Another option might be a new FreeClientResourceComplex or one that
also returns the id, so we can free it using an alternative means.
found using valgrind.
amended along ajax's suggestions
Maps are CARD8s, therefore checking for values above 255 is completely
unnecessary. Moreover, 0 is a valid value for maps, so the check wasn't
even correct to begin with. This fixes bug #22392, which was uncovered
by commit 280b7f92d7.
Signed-off-by: Ben Gamari <bgamari.foss@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Take the mapping of DixAccess bits to Flask permissions, move it
into the header file, break up the extremely long lines, and
annotate the permission names with the bit being referenced.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
The new clipping rules:
- client clips happen after transformation
- pixels unavailable due to the hierarchy are undefined
The first one is implemented in pixman; the second one is realized by
making a copy of window sources (to prevent out-of-bounds access).
Wrong check for inputInfo.pointer resulted in a SW cursor being rendered when
the pointer left the screen (in a Xinerama setup).
We must call the sprite rendering function if
- SW cursors are enabled, or
- The current device is not the VCP and not attached to the VCP.
Reported-by: Gordon Yuan <GordonYuan@viatech.com.cn>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously when compiling on freebsd amd64 we'd end up at xi86
block (line 1315) which would define mem_barrier and write_mem_barrier
to be NOP's. Instead they should be valid, as per the linux amd64 setup.
This stops the hangs experienced by many when using the nv driver
which would hang due to out of order dma requests as noticed in
http://bugs.freedesktop.org/show_bug.cgi?id=3168
Signed-off-by: Benjamin Close <Benjamin.Close@clearchain.com>
