Slightly more funky would be to poke around in the CRTC, but that should
require master. As it stands this should help verify that what X is
supplying to the driver matches user expectations
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
virtual.c:1081:6: warning: variable 'width' is used uninitialized
whenever 'if' condition is true [-Wsometimes-uninitialized]
if (clone->dst.mode.id == 0) {
^~~~~~~~~~~~~~~~~~~~~~~
virtual.c:1092:6: note: uninitialized use occurs here
if (width == clone->width && height == clone->height)
^~~~~
virtual.c:1081:2: note: remove the 'if' if its condition is always false
if (clone->dst.mode.id == 0) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
virtual.c:1079:11: note: initialize the variable 'width' to silence this warning
int width, height;
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Third one-line patch to fix copying from the tainted user argument into
the socket's path buffer. This time, give in and just use snprintf() as
it guarrantees that it will not write more than 'n' characters and that
the last is a NUL byte.
Suggested-by: Zdenek Kabelac <zkabelac@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Somebody (me) confused it with snprintf() and put the string length in
the wrong location. Also note that strncpy() does not NUL terminate long
strings.
Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having the pkgconfig present doesn't always necessarily imply the
headers are installed correctly - just fail over gracefully for xinerama
and intel-virtual-output
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Adam Sampson spotted that
"It's possible (but not very sensible) to exec a program with an empty
argument list, so argv[0] is not necessarily a valid pointer. For
example:
$ cat exec0.c
int main(int argc, char *argv[]) {
char *empty[1] = { NULL };
execvp(argv[1], empty);
perror("execvp");
return 1;
}
$ ./exec0 /usr/libexec/xf86-video-intel-backlight-helper
Usage: (null) <iface>
"
He sensibly suggested that we hardcode the program name to avoid the
NULL dereference. Being the paranoid type, we should also be careful not
to write to any file descriptors outside of our control (i.e. stderr),
so disable the messages unless we are debugging.
Reported-by: Adam Sampson
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
- don't allow '/' in the interface name to avoid escaping the /sys
hierarchy
- check snprintf() return value for overflow.
Problems reported by Adam Sampson. Thanks.
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Matti reported a few outdated links to intellinuxgraphics.org, now
superseded by 01.org.
Reported-by: Matti Hämäläinen <ccr@tnsp.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This is fortunately a no-op, as it gets initialized to zero already
(that is the pixmap is writeable). However, we may as well do the right
thing...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail to disable the remote output during initialisation, copy the
current configuration in order to try and keep the bookkeeping in order.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Only mark an output as disabled if we do successfully disable it. This
will require a little more work to make sure that such errors are
cleanly propagated back to the host...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sigh. A serious mixup of integer promotion rules and wraparound caused
the damage computation for small regions to be completely bogus.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we walk the output lists in the same order as they are listed by
RandR, we are more likely to hit favourable priority sorting. E.g. the
user is likely to setup the outputs in the same order as listed, meaning
fewer CRTC transitions etc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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>