- 02 Oct, 2012 1 commit
-
-
David Howells authored
Only refer to the DRM UAPI headers (drm.h, drm_mode.h and drm_sarea.h) from within drmP.h and drm_crtc.h, and use #include <...> to refer to them so that when the UAPI split happens they can still be accessed. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Dave Airlie <airlied@redhat.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by:
Dave Jones <davej@redhat.com>
-
- 23 Aug, 2012 1 commit
-
-
Ville Syrjälä authored
DRM_MODE() macro doesn't initialize the type of the base drm object. When a copy is made of the mode, the object type is overwritten with zero, and the the object can no longer be found by drm_mode_object_find() due to the type check failing. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 21 Aug, 2012 1 commit
-
-
Damien Lespiau authored
Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 19 Jul, 2012 1 commit
-
-
Daniel Vetter authored
It's unused. At it confused me quite a bit until I've discovered that. Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
- 12 Jun, 2012 1 commit
-
-
Paulo Zanoni authored
Before Kernel 3.5, no one was checking for the return value of drm_connector_attach_property, so we never noticed that we were unable to create some properties. Commit "drm: WARN() when drm_connector_attach_property fails" added a WARN when we fail to create a property, and the transition from "connector properties" to "object properties" changed the warning message a little bit. On i915 machines with many TV connectors we hit the maximum number of properties (since each TV connector uses a lot of properties), so we get a few backtraces in our logs. This commit increases the maximum number of properties to 24 hoping we'll have enough room for everybody. Chris suggested that we convert this code to "lists", but I believe this conversion can come after we make sure people's dmesgs are not spammed by our driver. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reported-by:
-
- 22 May, 2012 4 commits
-
-
Rob Clark authored
The omapdrm driver uses this for setting per-overlay rotation. It is likely also useful for setting YUV->RGB colorspace conversion matrix, etc. Signed-off-by:
Rob Clark <rob@ti.com> Reviewed-by:
-
Rob Clark authored
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]). [airlied: 1LL -> 1ULL] Signed-off-by:
-
Laurent Pinchart authored
The DRM mode config functions structure declared by drivers and pointed to by the drm_mode_config funcs field is never modified. Make it a const pointer. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Rob Clark <rob.clark@linaro.org> Reviwed-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
-
Laurent Pinchart authored
Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
- 17 May, 2012 5 commits
-
-
Paulo Zanoni authored
The i915 driver needs this for the rotation and overscan compensation properties. Other drivers might need this too. Reviewed-by:
Rob Clark <rob.clark@linaro.org> Tested-by:
-
Paulo Zanoni authored
This way, we don't need to count every time, so we're a little bit faster and code is a little bit smaller. Change suggested by Ville Syrjälä. Reviewed-by:
-
Paulo Zanoni authored
Useless for connector properties (since they already have their own ioctls), but useful when we add properties to CRTCs, planes and other objects. Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by:
-
Paulo Zanoni authored
For now, only connectors have it. In the future, all objects that need properties should use it. Since the structure is referenced inside struct drm_mode_object, we will be able to deal with object properties without knowing the real type of the object. Reviewed-by:
-
Paulo Zanoni authored
Also return void instead of int. We have more than 100 callers and no one checks for the return value. If this function fails the property won't be exposed by the get/set ioctls, but we should probably survive. If this starts happening, the solution will be to increase DRM_CONNECTOR_MAX_PROPERTY and recompile the Kernel. Signed-off-by:
-
- 27 Apr, 2012 1 commit
-
-
Adam Jackson authored
Requiring the first byte of the EDID base block header to be 0 means we don't fix up as many transfer errors as we could. Instead have the callers specify whether it's meant to be block 0 or not, and conditionally run header fixup based on that. Bugzilla: https://bugzilla.redhat.com/812890 Signed-off-by:
Adam Jackson <ajax@redhat.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 20 Apr, 2012 4 commits
-
-
Adam Jackson authored
It won't find any, yet. Fix up callers to match: standard mode codes will look prefer r-b modes for a given size if present, EST3 mode codes will look for exactly the r-b-ness mentioned in the mode code. This might mean fewer modes matched for EST3 mode codes between now and when the DMT mode list regrows the r-b modes, but practically speaking EST3 codes don't exist in the wild. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Ville Syrjälä authored
These functions return the chroma subsampling factors for the specified pixel format. Signed-off-by:
-
Ville Syrjälä authored
This function returns the bytes per pixel value based on the pixel format and plane index. Signed-off-by:
-
Ville Syrjälä authored
There will be a need for this function in drm_crtc.c later. This avoids making drm_crtc.c depend on drm_crtc_helper.c. Signed-off-by:
-
- 20 Mar, 2012 1 commit
-
-
Carsten Emde authored
Broken monitors and/or broken graphic boards may send erroneous or no EDID data. This also applies to broken KVM devices that are unable to correctly forward the EDID data of the connected monitor but invent their own fantasy data. This patch allows to specify an EDID data set to be used instead of probing the monitor for it. It contains built-in data sets of frequently used screen resolutions. In addition, a particular EDID data set may be provided in the /lib/firmware directory and loaded via the firmware interface. The name is passed to the kernel as module parameter of the drm_kms_helper module either when loaded options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel commandline parameter drm_kms_helper.edid_firmware=edid/1280x1024.bin It is also possible to restrict the usage of a specified EDID data set to a particular connector. This is done by prepending the name of the connector to the name of the EDID data set using the syntax edid_firmware=[<connector>:]<edid> such as, for example, edid_firmware=DVI-I-1:edid/1920x1080.bin in which case no other connector will be affected. The built-in data sets are Resolution Name -------------------------------- 1024x768 edid/1024x768.bin 1280x1024 edid/1280x1024.bin 1680x1050 edid/1680x1050.bin 1920x1080 edid/1920x1080.bin They are ignored, if a file with the same name is available in the /lib/firmware directory. The built-in EDID data sets are based on standard timings that may not apply to a particular monitor and even crash it. Ideally, EDID data of the connected monitor should be used. They may be obtained through the drm/cardX/cardX-<connector>/edid entry in the /sys/devices PCI directory of a correctly working graphics adapter. It is even possible to specify the name of an EDID data set on-the-fly via the /sys/module interface, e.g. echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware The new screen mode is considered when the related kernel function is called for the first time after the change. Such calls are made when the X server is started or when the display settings dialog is opened in an already running X server. Signed-off-by:
Carsten Emde <C.Emde@osadl.org> Signed-off-by:
-
- 15 Mar, 2012 6 commits
-
-
Dave Airlie authored
In order to get correct ordering at hot-unplug for userspace, we need to tear down all the sysfs bits at the correct time. This adds a helper to allow drivers to remove the sysfs nodes for all connectors. Signed-off-by: -
Ville Syrjälä authored
Add a helper function to copy a display mode. Use it in drm_mode_duplicate() and nouveau mode_fixup hooks. Signed-off-by:
-
Ville Syrjälä authored
The blob property data is always allocated immediately after the object header. No need for the extra indirection when accessing it, just use a flexible array member. Signed-off-by:
-
Ville Syrjälä authored
Check drm_mode_object_get() return value everywhere. Signed-off-by:
-
Ville Syrjälä authored
Change drm_mode_attachmode_crtc() to take an "all or nothing" approach. If an error is returned, there are no side effects visible. Also change the function to always duplicate the mode passed in. Also change the function to not give up when it finds the first connector without and encoder. A simpler approach would be to just remove the function completely as it's unused currently. Signed-off-by:
-
Ville Syrjälä authored
The drm_display_mode type is a bitmask so it should be unsigned. Signed-off-by:
-
- 16 Feb, 2012 1 commit
-
-
Dave Airlie authored
For the simple KMS driver case we need some more info about what the preferred depth and if a shadow framebuffer is preferred. I've only added this for intel/radeon which support the dumb ioctls so far. If you need something really fancy you should be writing a real X.org driver. v2: drop cursor information, just return an error from the cursor ioctls and we can make userspace fallback to sw cursor in that case, cursor info was getting too messy, best to start smaller. Signed-off-by:
-
- 09 Feb, 2012 2 commits
-
-
Sascha Hauer authored
Creating a range property is a common pattern, so create a convenience function for this and use it where appropriate. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Sascha Hauer authored
Creating an enum property is a common pattern, so create a convenience function for this and use it where appropriate. Signed-off-by:
-
- 03 Feb, 2012 1 commit
-
-
Sascha Hauer authored
drm_mode_crtc_set_gamma_size returns boolean true for success and false for failure. This is not very kernel conform, so change it to return 0 for success and a propert error code otherwise. Noone checks the return value, so no users have to be fixed. Signed-off-by:
-
- 13 Jan, 2012 1 commit
-
-
Ben Skeggs authored
There exists at least one NVIDIA GPU (Quadro NVS 300) that has a DMS-59 connector which is capable of supporting DisplayPort, TMDS and VGA on a single connector. We need to bump the allowed encoder limit to support all three configs. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
- 05 Jan, 2012 1 commit
-
-
Rob Clark authored
In cases where the scanout hw is sufficiently similar between "overlay" and traditional crtc layers, it might be convenient to allow the driver to create internal drm_plane helper objects used by the drm_crtc implementation, rather than duplicate code between the plane and crtc. A private plane is not exposed to userspace. Signed-off-by:
-
- 20 Dec, 2011 2 commits
-
-
Ville Syrjälä authored
Otherwise each driver would need to keep the information inside their own framebuffer object structure. Also add offsets[]. BOs on the other hand are driver specific, so those can be kept in driver specific structures. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
- 06 Dec, 2011 6 commits
-
-
Jesse Barnes authored
Including a comment about what the locks are for. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
-
Jesse Barnes authored
This is actually a core structure with a big future ahead of it. Make it a little less mysterious. Signed-off-by:
-
Jesse Barnes authored
Just fix the wrapping mostly. Signed-off-by:
-
Jesse Barnes authored
This is a core mode setting structure that deserves a little verbiage. Signed-off-by:
-
Jesse Barnes authored
We never used initial_x/y or the force_encoder_id, so drop those fields and proide a basic description of the others. Really, the ELD bits belong in drm_display_info rather than directly in the connector, but that's a separate cleanup. Signed-off-by:
-
Jesse Barnes authored
Just some basic comments about the place and function of the structure and fields. Signed-off-by:
-
