- 17 5月, 2012 3 次提交
-
-
由 Paulo Zanoni 提交于
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: NEugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: NRob Clark <rob.clark@linaro.org> Tested-by: NRob Clark <rob.clark@linaro.org> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Paulo Zanoni 提交于
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: NEugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: NRob Clark <rob.clark@linaro.org> Tested-by: NRob Clark <rob.clark@linaro.org> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Paulo Zanoni 提交于
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: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NRob Clark <rob.clark@linaro.org> Tested-by: NRob Clark <rob.clark@linaro.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 27 4月, 2012 1 次提交
-
-
由 Adam Jackson 提交于
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/812890Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NAlex Deucher <alexdeucher@gmail.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 20 4月, 2012 4 次提交
-
-
由 Adam Jackson 提交于
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: NAdam Jackson <ajax@redhat.com> Tested-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
These functions return the chroma subsampling factors for the specified pixel format. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
This function returns the bytes per pixel value based on the pixel format and plane index. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 20 3月, 2012 1 次提交
-
-
由 Carsten Emde 提交于
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: NCarsten Emde <C.Emde@osadl.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 15 3月, 2012 6 次提交
-
-
由 Dave Airlie 提交于
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: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
Add a helper function to copy a display mode. Use it in drm_mode_duplicate() and nouveau mode_fixup hooks. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
Check drm_mode_object_get() return value everywhere. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
The drm_display_mode type is a bitmask so it should be unsigned. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 17 2月, 2012 1 次提交
-
-
由 Dave Airlie 提交于
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: NDave Airlie <airlied@redhat.com>
-
- 09 2月, 2012 2 次提交
-
-
由 Sascha Hauer 提交于
Creating a range property is a common pattern, so create a convenience function for this and use it where appropriate. Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Sascha Hauer 提交于
Creating an enum property is a common pattern, so create a convenience function for this and use it where appropriate. Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 03 2月, 2012 1 次提交
-
-
由 Sascha Hauer 提交于
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: NSascha Hauer <s.hauer@pengutronix.de> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 13 1月, 2012 1 次提交
-
-
由 Ben Skeggs 提交于
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: NBen Skeggs <bskeggs@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 05 1月, 2012 1 次提交
-
-
由 Rob Clark 提交于
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: NRob Clark <rob@ti.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 20 12月, 2011 2 次提交
-
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ville Syrjälä 提交于
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 06 12月, 2011 9 次提交
-
-
由 Jesse Barnes 提交于
Including a comment about what the locks are for. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jesse Barnes 提交于
This is actually a core structure with a big future ahead of it. Make it a little less mysterious. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jesse Barnes 提交于
Just fix the wrapping mostly. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jesse Barnes 提交于
This is a core mode setting structure that deserves a little verbiage. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jesse Barnes 提交于
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: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jesse Barnes 提交于
Just some basic comments about the place and function of the structure and fields. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jesse Barnes 提交于
Just basic verbiage. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jesse Barnes 提交于
Remove stale entries and update with the latest stuff. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jesse Barnes 提交于
Doesn't really belong here anyway. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 30 11月, 2011 1 次提交
-
-
由 Dave Airlie 提交于
This is used by nearly everyone including vmwgfx which doesn't generally use the fb helper. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 16 11月, 2011 2 次提交
-
-
由 Jesse Barnes 提交于
To properly support the various plane formats supported by different hardware, the kernel must know the pixel format of a framebuffer object. So add a new ioctl taking a format argument corresponding to a fourcc name from the new drm_fourcc.h header file. Implement the fb creation hooks in terms of the new mode_fb_cmd2 using helpers where the old bpp/depth values are needed. v2: create DRM specific fourcc header file for sharing with libdrm etc v3: fix rebase failure and use DRM fourcc codes in intel_display.c and update commit message v4: make fb_cmd2 handle field into an array for multi-object formats pull in Ville's fix for the memcpy in drm_plane_init apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb v5: add 'flags' field for interlaced support (from Ville) Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk> Reviewed-by: NRob Clark <rob.clark@linaro.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jesse Barnes 提交于
Planes are a bit like half-CRTCs. They have a location and fb, but don't drive outputs directly. Add support for handling them to the core KMS code. v2: fix ABI of get_plane - move format_type_ptr to the end v3: add 'flags' field for interlaced support (from Ville) Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk> Reviewed-by: NRob Clark <rob.clark@linaro.org> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 22 9月, 2011 1 次提交
-
-
由 Wu Fengguang 提交于
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio capabilities of the plugged monitor. This adds drm_edid_to_eld() for converting EDID to ELD. The converted ELD will be saved in a new drm_connector.eld[128] data field. This is necessary because the graphics driver will need to fixup some of the data fields (eg. HDMI/DP connection type, AV sync delay) before writing to the hardware ELD buffer. drm_av_sync_delay() will help the graphics drivers dynamically compute the AV sync delay for fixing-up the ELD. ELD selection policy: it's possible for one encoder to be associated with multiple connectors (ie. monitors), in which case the first found ELD will be returned by drm_select_eld(). This policy may not be suitable for all users, but let's start it simple first. The impact of ELD selection policy: assume there are two monitors, one supports stereo playback and the other has 8-channel output; cloned display mode is used, so that the two monitors are associated with the same internal encoder. If only the stereo playback capability is reported, the user won't be able to start 8-channel playback; if the 8-channel ELD is reported, then user space applications may send 8-channel samples down, however the user may actually be listening to the 2-channel monitor and not connecting speakers to the 8-channel monitor. According to James, many TVs will either refuse the display anything or pop-up an OSD warning whenever they receive hdmi audio which they cannot handle. Eventually we will require configurability and/or per-monitor audio control even when the video is cloned. CC: Zhao Yakui <yakui.zhao@intel.com> CC: Wang Zhenyu <zhenyu.z.wang@intel.com> CC: Jeremy Bush <contractfrombelow@gmail.com> CC: Christopher White <c.white@pulseforce.com> CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com> CC: Paul Menzel <paulepanter@users.sourceforge.net> CC: James Cloos <cloos@jhcloos.com> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Signed-off-by: NWu Fengguang <fengguang.wu@intel.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 04 8月, 2011 2 次提交
-
-
由 Thomas Reim 提交于
Provides function drm_edid_header_is_valid() for EDID header check and replaces EDID header check part of function drm_edid_block_valid() by a call of drm_edid_header_is_valid(). This is a prerequisite to extend DDC probing, e. g. in function radeon_ddc_probe() for Radeon devices, by a central EDID header check. Tested for kernel 2.6.35, 2.6.38 and 3.0 Cc: <stable@kernel.org> Signed-off-by: NThomas Reim <reimth@gmail.com> Reviewed-by: NAlex Deucher <alexdeucher@gmail.com> Acked-by: NStephen Michaels <Stephen.Micheals@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jesse Barnes 提交于
Drivers need to know the CEA version number in addition to other display info (like whether the display is an HDMI sink) before enabling certain features. So track the CEA version number in the display info structure. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 16 6月, 2011 1 次提交
-
-
由 Dave Airlie 提交于
Some RS690 chipsets seem to end up with floating connectors, either a DVI connector isn't actually populated, or an add-in HDMI card is available but not installed. In this case we seem to get a NULL byte response for each byte of the i2c transaction, so we detect this case and if we see it we don't do anymore DDC transactions on this connector. I've tested this on my RS690 without the HDMI card installed and it seems to work fine. Signed-off-by: NDave Airlie <airlied@redhat.com> Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
-
- 28 4月, 2011 1 次提交
-
-
由 Jesse Barnes 提交于
EDID 1.4 digital displays report the color spaces they support in the features block. Add support for grabbing this data and stuffing it into the display_info struct for driver use. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-