The high layers expect to receive a status code on error (on the
pessimistic assumption that the errno value will have been overwritten
by the time the failure is propagated all the way up), so convert
xf86drmMode.c to return -errno on an ioctl error and be consistent with
the rest of the libdrm API.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the available modes changes between the two GETCONNECTOR ioctls, that
caused the kernel to skip filling one array and led to a crash (as the size
of the allocated and initialised block of memory differed from the reported
size, and might be NULL if no modes were present at first).
This bug manifest its self on my machine due to spurious false positive
detections of a connected TV-out.
Fixes: http://bugs.freedesktop.org/show_bug.cgi?id=25912
Crash whilst probing modes
Based upon the similar fixes for the GETRESOURCES ioctls by Chris Wilson,
in the following commits:
commit e6c136ca7a
commit 85fb3e55fd
commit d1308f4fe7
Signed-off-by: Peter Clifton <pcjc2@cam.ac.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the count is 0, then the malloc is permitted to return NULL, so don't
throw an error in that case.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Peter Clifton hit an issue whereby he had a spurious TV hotplug event
that occurred between the two GETRESOURCES ioctls that caused the kernel
to skip filling one array and led to a crash (as the size of the
allocated and initialised block of memory differed from the reported
size).
Fixes: http://bugs.freedesktop.org/show_bug.cgi?id=25912
Crash whilst probing modes
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Peter Clifton <pcjc2@cam.ac.uk>