On a lone machine I had a vital fix for setting the destination tiling
bit inside the XY_PIXEL_BLT command. Sadly, I forgot about the fix before
the patch from another machine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is a sanity check that the pixmap is mapped for use by the CPU
prior to us actually using it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The current snapshot is 1.15.99.901, which means that the new feature
will first be available in 1.15.99.902.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The assumption that all paths prevalidate the restrictions upon creation
the bo are false. Some important paths try to force the bo creation in
order to meet client expectations (e.g. DRI). So we are faced with
impossible requests which must fail, so make sure we do report those
failures.
Bugzilla: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1289049
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If for some reason we have an fd, but no device path, use the likely
default path (derived from and validated against the major/minor of the
open device fd).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the post-modern world, the platform device nodes are handed to a
non-privileged Xserver by systemd/logind. We can then query the core for
our assigned fd rather than try to open the device for ourselves (which
would fail when trying to obtain DRM_MASTER status). A consequence is
that we then do not directly control DRM_MASTER status and must act as a
delegate of systemd.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
If we lock the glyph cache and then hit an error, we must make sure we
release our lock. An easy way would be not to lock when we may err.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On gen2 (like gen3), 8-bit destination surfaces are read into the Green
channel (and written to from the Green channel). Therefore the expected
alpha blending must instead be converted to colour blending.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75818
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
So that the lockless reads do not see the task complete signal prior to
marking the task as successful. Otherwise, we falsely detect that the
thread trapped a signal and kill them all.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The goal here is to predict when we are uploading an entire image though
multiple PutImage requests. If the image is small enough, then the
PutImage will be contained within a single request and the damage
tracking will be accurate.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes regression from
commit 1de1104064
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Feb 21 22:43:04 2014 +0000
sna: Use a hint to do whole image uploads inplace
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75549
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
One of the failure modes for execbuf is running out of memory - often
this is reported as a false ENOSPC (thanks shmemfs!). Because of this,
we should try to resubmit after we purge our caches.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
To handle sigtrapping of the threads, we allow the threads to handle
their async signals and upon hitting the trap, we kill the thread. All
the rest of the threads are reaped by the main xserver thread
afterwards.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Along one of the sw blt paths we failed to apply the offset for
Composite redirection.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73811
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By killing the threads and leaking their allocations - marginally
preferrable to losing the entire Xserver.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For the moment, this still leaves open the vexing question of how to
protect the multi-threaded variants, but it should provide more shelter
for extreme OOM.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The fallback xf86InitialConfiguration() is another function that may
explode if called without any CRTCs attached.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The xserver may crash if we try to setup colormap handling without any
CRTCs, so don't.
Suggested-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris would like to humbly apologise for making these changes to the
OpenBSD code blind, and to thank Mark and Jonathan for their support
and understanding.
X always sends MappingNotify events (there is no way for the client
to ignore them). In particular, MappingNotify would be sent after a VT
switch, and this would knock out our ability to track the cursor..
Reported-by: Raul Dias <raul@dias.com.br>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75115
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Since the helper is a standalone app, the usual xserver rules of not using
stdio because of signal handling don't apply.
And since the helper does run with elevated rights, it is important to keep
the code KISS so that it can be audited easily.
This commit replaces the hard to read "raw" read loop with a much simpler
loop using fgets, improving readability of the code.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Event though we've failed to open the backlight normally, we may still be
running under a suid-root xserver, so drop any elevated rights before
executing what we hope will be pkxec.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Even though we've failed to open the backlight normally, we may still be
running under a suid-root xserver, so use the servers build in System instead
of system so as to properly drop root rights.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>