| Age | Commit message (Collapse) | Author |
|---|
|
We really have to do this to avoid surprises when extending the ABI
later on. Especially when growing the structures.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
For the sake of simplicity, KMS support can always be considered
present on DragonFly.
If some particular version doesn't support KMS yet, appropriate
checks are already done in Dports's x11-drivers/ Makefiles and
KMS-enabled driver packages don't get built.
Signed-off-by: François Tigeot <ftigeot@wolfpond.org>
Signed-off-by: Maarten Lankhorst <dev@mblankhorst.nl>
|
|
DRM_IOCTL_MODE_SETPLANE crtc_x, crtc_y are s32.
This is to allow a destination location that is partially off screen.
Make this more obvious to users of libdrm by using signed crtc_x/_y
parameters for drmModeSetPlane() as well.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
|
|
Add the missing implementation of drmCheckModesettingSupported()
to detect KMS support on FreeBSD (and GNU/kFreeBSD).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72847
Signed-off-by: Konstantin Belousov <kib@freebsd.org>
Signed-off-by: Robert Millan <rmh@freebsd.org>
|
|
Fixes valgrind complaints in the modesetting driver. I tried to
follow each ioctl's pattern for whether it was initializing just the
in values, or both in and out values.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
If we have valid timings, we can at least set width/height to
*something*, which is I think at least less confusing than always
seeing width/height of zero. At least modeprint and modetest
seem to expect width/height to mean something.
Signed-off-by: Rob Clark <rob@ti.com>
|
|
A bitmask property is similar to an enum. The enum value is a bit
position (0-63), and valid property values consist of a mask of
zero or more of (1 << enum_val[n]).
Signed-off-by: Rob Clark <rob@ti.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
New library calls:
- drmModeObjectGetProperties
- drmModeFreeObjectProperties
- drmModeObjectSetProperties
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Rob Clark <rob@ti.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
|
|
work. sizeof() treats such parameters as pointers.
Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
|
|
Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
|
|
drmModeGetPlaneResources() and drmModeGetPlane() leaked in one error
path.
Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
|
|
Add structs and functions necessary for the new plane and fb handling code,
including a new header, drm_fourcc.h, that includes the surface formats
supported by various DRM drivers.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
Both drmIoctl and ioctl define second argument as unigned long.
Debugging/tracing tools (like strace or valgrind) on 64-bit machines see
different request value for ioctls with 32nd bit set, because casting
signed int to unsigned long extends 32nd bit to upper word, so 0x80000000
becomes 0xFFFFFFFF80000000)
Nobody noticed because higher 32 bits are chopped off on their way to kernel.
|
|
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
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 e6c136ca7a4c54457b48be1aec2be024b3e4a28d
commit 85fb3e55fdb7af9b5f59c1ec0f15d1950e601b05
commit d1308f4fe7f94aae51ca9f70947aea8e09597f37
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>
|
|
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>
|
|
Conflicts:
include/drm/drm.h
|
|
|
|
Conflicts:
include/drm/drm.h - RMFB had its signature changed to avoid uint32_t
|
|
|
|
|
