This allows untrusted clients to destroy their own windows when they
have been reparented by a trusted window manager.
(cherry picked from commit 4559d2ace6)
Previously, three extensions were defined as "trusted" by the extension:
BIG-REQUESTS, XC-MISC, and XPrint. No other extensions were permitted
to be used by untrusted clients.
In commit 8b5d21cc1d this was changed for
some reason. Return to the old, compatible behavior.
(cherry picked from commit 6045506be0)
When using any XAAPixmapOps, we call into unknown but freshly
unwrapped callbacks (like fb ones). Unlike the XAA*Fallback calls,
we did so without syncing first, exposing us to all kinds of
synchronisation issues.
I believe that the rendering errors appeared now because *PaintWindow
vanished (e4d11e58), and we just use miPaintWindow instead. This
takes a less direct route to the hw and ends up at
PolyFillRectPixmap, which very often left drawing artifacts.
We now sync accordingly, and no longer get the rendering artifacts i
was methodically reproducing on radeonhd, radeon, unichrome...
Also, in order to allow driver authors to remove extensive syncing
or flushing to hide this issue, create XAA_VERSION_ defines, put
them in xaa.h and bump the patchlevel.
(novell bug #435791)
(cherry picked from commit 59f9fb4b8c)
When setting the depth to 24, leave bpp unset so the logic to pick
a supported value is used instead of ignoring the driver's preference
and forcing 32 bpp.
(cherry picked from commit 991c88b754)
The swrast DRI provider gets pushed on the glx provider stack at every
server generation, so the stack turns into a circular list on regen.
X.Org bug#18388 <https://bugs.freedesktop.org/show_bug.cgi?id=18388>
(cherry picked from commit d3d6be4948)
When the linux kernel sets the NX bit vm86 segfaults when it tries to execute
code in memory that is not marked EXEC. Such code gets called whenever
we return from a VBIOS call to signal the calling program that the call
is actually finished and that we are not trapping for other reasons (like
IO accesses).
Use mprotect(2) to set these memory ranges PROT_EXEC.
(cherry picked from commit a9e20306fb)
The precedence of == is higher than that of &, so that code was
probably buggy.
xf86Init.c: In function 'DoModalias':
xf86Init.c:300: warning: suggest parentheses around comparison in operand of &
xf86Init.c:304: warning: suggest parentheses around comparison in operand of &
xf86Init.c:308: warning: suggest parentheses around comparison in operand of &
(cherry picked from commit ffaaa1a198)
It was accidentally lost when factoring out __glXDRIdoReleaseTexImage, so this
is a regression fix and should probably be backported to server-1.5-branch.
(cherry picked from commit a4d62bbf21)
Works around a silly bug in the kernel that causes wakeup storms after
too many keypresses. Should fix the kernel bug too, but this at least
keeps the idle wakeup count below 1000/sec.
(cherry picked from commit 446d9443ce)
This consists of two parts:
In the implicit server layout, ignore those drivers when looking for a core
device.
And after finishing the server layout, run through the list of devices and
remove any that use mouse or kbd.
AEI is mutually exclusive with the kbd and mouse drivers, so pick either - or.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
(cherry picked from commit c264826da9)
Usually, the console is set to RAW in the kbd driver. If we hotplug all input
devices (i.e. the evdev driver for keyboards) and the console is left as-is.
As a result, the evdev driver must put an EVIOCGRAB on the device to avoid
characters leaking onto the console. This again breaks many things, amongst
them lirc, in-kernel mouse button emulation and HAL.
This patch sets the console to RAW if AllowEmptyInput is on.
Use-cases:
1. AEI is off
1.1. Only kbd driver is used - behaviour as-is.
1.2. kbd and evdev driver is used: if evdev does not grab the device,
duplicate events are generated.
2. AEI is on
2.1. Only evdev driver is used - behaviour as-is, but evdev does not need
to grab the device anymore.
2.2. evdev and kbd are used: duplicate key events are generated if evdev
does not grab the device.
1.2 is a marginal use-case that can be fixed by adding a "grab" option to the
evdev driver (update of xorg.conf is needed).
2.2 is an issue. If we have no ServerLayout section, AEI is on, but devices
specified in the xorg.conf are still added [1], resulting in duplicate events.
This is a common configuration and needs sorting out.
[1] 2eaed4a10f
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit d936a4235c)
If HAL is restarted, the device list is sent to the server again, leading
first to duplicate devices (and thus duplicate events), and later to a
FatalError "Too many input devices."
dev->config_info contains the UDI for the device. If the UDI of a new devices
is equal to one we already have in the device list, just ignore it.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
(cherry picked from commit 6c45185955)
- This breaks on the 2nd server generation.
- No other subsystem seems to NULL their key.
- This should fix bug 17982.
(cherry picked from commit 5b336585a4)
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.
(cherry picked from commit b736f477f5)
Very cute, Samsung, not only do you claim to be 16cm by 9cm in the
global size record, you also claim to be 160mm by 90mm in the detailed
timings. Grrr.
(cherry picked from commit bd9c6b3a4d)
Fixes a segfault when trying to activate a DGA mode without checking
whether DGA modesetting is at all possible.
(cherry picked from commit 1feb69eb63)
Some BIOSes (hi XGI!) will attempt to enumerate the PCI bus by asking
for the config space of every possible device number. This despite
perfectly functional BIOS methods to enumerate the bus exactly.
(cherry picked from commit a57b2f172c)
Note: DevPrivateKey is now pointer-to-int, which means
each key now needs to point to some global storage of
size at least sizeof(int).
(cherry picked from commit b6ab114212)
If we update key types from core, and groups 2 - n have a canonical type but
the same symbols as the explicit type of group 1, assume that it was a core
sym duplication according to Section 12.4 of the XKB Protocol Spec.
Ignore the canonical types and pretend there's only one group for the key -
with the explicit key type.
The protocol spec does not cover this case, so we have to guess here.
(cherry picked from commit 30c3c13f10)
According to Section 12.4 of the XKB Protocol Spec, if a key only has a single
group but the keyboard has multiple groups defined, the core description of
the key is a duplication of the single group across all symbols. i.e.
G1L1 G1L2 G1L1 G1L2 G1L3 G1L4 G1L3 G1L4
The previous code generated G1L1 G1L2 G1L3 G1L4 G1L3 G1L4, leading to
"invented" groups when the process is reversed.
Note that this creates wrong key types on reconstruction from core to xkb,
i.e. any single-group key with a key type that is not one of the canonical
four (Sec 12.2.3), will get the assigned type on group 1, and a canonical type
for the other gruops.
X.Org Bug 14373 <http://bugs.freedesktop.org/show_bug.cgi?id=14373>
(cherry picked from commit ae986d1c73)
And some cosmetic changes to use stuff->change consistently.
Signed-off-by: Peter Hutterer <peter.hutterer@redhat.com>
(cherry picked from commit 8c46505d7d)
