[PATCH 0/3] Provide workarounds to use DRM/KMS with broken graphics hardware

[Carsten Emde]

In the good old days when graphics parameters were configured explicitly
in a file called xorg.conf, even broken hardware could be managed.

Today, with the advent of Kernel Mode Setting, a graphics board is
either correctly working because all components follow the standards -
or the computer is unusable, because the screen remains dark after
booting or displays the wrong area. Cases when this happens are:
- The BIOS assumes that an LVDS is always connected, even if it isn't.
- The graphics board does not recognize the monitor.
- The graphics board is unable to detect any EDID data.
- The graphics board incorrectly forwards EDID data to the driver.
- The monitor sends bogus EDID data.
- A KVM sends its own EDID data instead of querying the connected monitor.
- The brightness setting of the panel backlight does not work.
- Any combination of the above.
Adding the kernel parameter "nomodeset" helps in most cases, but causes
restrictions later on.

The three patches of this series add module parameters to the
drm_kms_helper module that
1. allow to load an EDID data set via the firmware interface,
2. provide a module parameter to selectively enable or disable a
graphics port,
3. provide a module parameter to select inverted brightness.

EDID data sets along with source files are provided for commonly used
screen resolutions (1024x768, 1280x1024, 1680x1050, 1920x1080).

Please note that these patches neither fix a kernel bug nor provide any
extra functionality. They simply work around broken hardware that
otherwise would be either unusable or usable in a very restricted way.
The patches do not modify the current functionality of the related
components in any way, unless the kernel is configured accordingly
and/or the newly provided module parameters are set.

-Carsten. 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drivers-gpu-drm-i915-invert-backlight-brightness

[Carsten Emde]

Following the documentation of the Legacy Backlight Brightness (LBB)
Register in the configuration space of some Intel PCI graphics adapters,
setting the LBB register with the value 0x0 causes the backlight to be
turned off, and 0xFF causes the backlight to be set to 100% intensity
(http://download.intel.com/embedded/processors/Whitepaper/324567.pdf).
At least one of our test systems, however, turns the backlight off at
0xFF and sets it to maximum intensity at 0. In consequence, the screen
of this systems becomes dark at an early boot stage which makes it
unusable. The same inversion applies to the BLC_PWM_CTL I915 register.
This problem was introduced in kernel version 2.6.38 when the PCI device
of this system was first supported by the i915 KMS module.

This patch adds a module parameter to invert the backlight brightness
value before writing and after reading which makes the affected notebook
usable again.

Signed-off-by: Carsten Emde 

---
 Documentation/kernel-parameters.txt |9 +
 drivers/gpu/drm/i915/intel_panel.c  |   14 ++
 2 files changed, 23 insertions(+)

Index: linux-3.3-rc6/Documentation/kernel-parameters.txt
===
--- linux-3.3-rc6.orig/Documentation/kernel-parameters.txt
+++ linux-3.3-rc6/Documentation/kernel-parameters.txt
@@ -975,6 +975,15 @@ bytes respectively. Such letter suffixes
 
i810=   [HW,DRM]
 
+   i915.invert_brightness
+   [DRM] Invert the sense of the variable that is used to
+   set the brightness of the panel backlight. Normally a
+   value of 0 indicates backlight switched off, and the
+   maximum value sets the backlight to maximum brightness.
+   If this parameter is specified, a value of 0 sets the
+   backlight to maximum brightness, and the maximum value
+   switches the backlight off.
+
i8k.ignore_dmi  [HW] Continue probing hardware even if DMI data
indicates that the driver is running on unsupported
hardware.
Index: linux-3.3-rc6/drivers/gpu/drm/i915/intel_panel.c
===
--- linux-3.3-rc6.orig/drivers/gpu/drm/i915/intel_panel.c
+++ linux-3.3-rc6/drivers/gpu/drm/i915/intel_panel.c
@@ -28,6 +28,7 @@
  *  Chris Wilson 
  */
 
+#include 
 #include "intel_drv.h"
 
 #define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
@@ -191,6 +192,10 @@ u32 intel_panel_get_max_backlight(struct
return max;
 }
 
+static bool brightness_inverted;
+MODULE_PARM_DESC(brightness_inverted, "Backlight brightness value is inverted "
+   "(0 = max brightness, max value = dark)");
+module_param_named(brightness_inverted, brightness_inverted, bool, 0600);
 u32 intel_panel_get_backlight(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -212,6 +217,10 @@ u32 intel_panel_get_backlight(struct drm
}
 
DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
+   if (brightness_inverted) {
+   u32 max = intel_panel_get_max_backlight(dev);
+   val = max - val;
+   }
return val;
 }
 
@@ -229,6 +238,11 @@ static void intel_panel_actually_set_bac
 
DRM_DEBUG_DRIVER("set backlight PWM = %d\n", level);
 
+   if (brightness_inverted) {
+   u32 max = intel_panel_get_max_backlight(dev);
+   level = max - level;
+   }
+
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drivers-gpu-drm-add-disable-enable-connector.patch

[Carsten Emde]

Some recent integrated graphics chipset, notably Intel's "Pineview", also
provide on-chip LVDS support. As an extra service, the LVDS interface supplies
EDID data - irrespective of whether an LVDS panel is connected or not. The
drm_mode_getresources() function, therefore, causes Xorg to always include
the LVDS panel into the display and initialize a separate screen for it. e.g.
(II) intel(0): Output LVDS1 connected
(II) intel(0): Output VGA1 connected
(II) intel(0): Using spanning desktop for initial modes
(II) intel(0): Output LVDS1 using initial mode 1024x768 +0+0
(II) intel(0): Output VGA1 using initial mode 1280x1024 +1024+0
which is not what you want, if the only connected screen is a VGA monitor.
One would assume that the BIOS settings of such systems would allow to
separately enable or disable LVDS support; unfortunately, systems have been
found in the wild that do not provide this feature.

This patch introduces the module parameter "disable_connector" of the
drm_kms_helper module that may specify the name of the connector to be
considered disabled, e.g.
  # cat /etc/modprobe.d/drm_kms_helper.conf 
  options drm_kms_helper disable_connector=LVDS-1
which lets Xorg correctly initialize the screen, e.g.
(II) intel(0): Output LVDS1 disconnected 
(II) intel(0): Output VGA1 connected
(II) intel(0): Using exact sizes for initial modes 
(II) intel(0): Output VGA1 using initial mode 1280x1024 +0+0

A second scenario applies to broken graphics adapters that are unable to
correctly detect connected monitors and end up in a situation where
the default screen resolution of 1024x768 is selected that may not be
appropriate, e.g.
(II) intel(0): Output VGA1 disconnected
(II) intel(0): Output HDMI1 disconnected
(II) intel(0): Output DP1 disconnected
(II) intel(0): Output HDMI2 disconnected
(II) intel(0): Output DP2 disconnected   
(WW) intel(0): No outputs definitely connected, trying again...
(II) intel(0): Output VGA1 disconnected
(II) intel(0): Output HDMI1 disconnected
(II) intel(0): Output DP1 disconnected
(II) intel(0): Output HDMI2 disconnected
(II) intel(0): Output DP2 disconnected
(WW) intel(0): Unable to find connected outputs - setting 1024x768 initial 
framebuffer 

This patch introduces a second module parameter "enable_connector" of the
drm_kms_helper module that may specify the name of the connector to be
taken as connected, e.g.
  # cat /etc/modprobe.d/drm_kms_helper.conf 
  options drm_kms_helper enable_connector=VGA-1
which lets Xorg correctly initialize the screen, e.g.
(II) intel(0): Output VGA1 connected
(II) intel(0): Output HDMI1 disconnected
(II) intel(0): Output DP1 disconnected
(II) intel(0): Output HDMI2 disconnected
(II) intel(0): Output DP2 disconnected
(II) intel(0): Using exact sizes for initial modes
(II) intel(0): Output VGA1 using initial mode 1280x1024 +0+0

Signed-off-by: Carsten Emde 

---
 Documentation/kernel-parameters.txt |   13 
 drivers/gpu/drm/drm_crtc.c  |   15 ++---
 drivers/gpu/drm/drm_crtc_helper.c   |3 ++
 drivers/gpu/drm/drm_fb_helper.c |   39 ++--
 include/drm/drm_crtc.h  |3 +-
 5 files changed, 66 insertions(+), 7 deletions(-)

Index: linux-3.3-rc6/Documentation/kernel-parameters.txt
===
--- linux-3.3-rc6.orig/Documentation/kernel-parameters.txt
+++ linux-3.3-rc6/Documentation/kernel-parameters.txt
@@ -713,12 +713,25 @@ bytes respectively. Such letter suffixes
The filter can be disabled or changed to another
driver later using sysfs.
 
+   drm_kms_helper.disable_connector=
+   The BIOS may always report that a panel is connected,
+   irrespective of whether it really is or not which may
+   lead to a bogus screen layout. This parameter is used
+   to explicitly disable a particular connector, e.g.
+   drm_kms_helper disable_connector=LVDS-1
+
drm_kms_helper.edid_firmware=
Broken monitors, graphic adapters and KVMs may
send no or broken EDID data sets. This parameter
allows to specify an EDID data set in the
/lib/firmware directory that is used instead.
 
+   drm_kms_helper.enable_connector=
+   Broken hardware may be unable to correctly discover a
+   monitor. This parameter is used to let the drm subsystem
+   assume that a monitor is present at the specified
+   connector, e.g. drm_kms_helper enable_connector=VGA-1
+
dscc4.setup=[NET]
 
earlycon=   [KNL] Output early console device and options.
Index: linux-3.3-rc6/drivers/gpu/drm/drm_crtc.c
===
--- linux-3.3-

[PATCH 1/3] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[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 load an EDID data set via the firmware interface.
It contains data sets of frequently used screen resolutions (1024x768,
1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
specified as a module parameter of the drm_kms_helper module, e.g.
options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
command line parameter.

In addition, an EDID data set can be specified 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.

EDID data source files are provided for documentation purpose and as a
template to create EDID data sets for other screen resolutions. Note
that source compilation is not part of the build process, but needs to
be done manually, e.g.

#!/bin/bash
cd firmware/edid
for i in [1-9]*.S
do
  base=`echo $i | sed "s/\.S$//"`
  cc -c $base.S
  objcopy -O ihex $base.o $base.bin.ihex
  dos2unix $base.bin.ihex 2>/dev/null
done

The 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-/edid entry in the /sys/devices PCI directory
of a correctly working graphics adapter.

Signed-off-by: Carsten Emde 

---
 Documentation/kernel-parameters.txt |6 
 drivers/gpu/drm/Kconfig |   10 +
 drivers/gpu/drm/Makefile|3 
 drivers/gpu/drm/drm_crtc_helper.c   |8 -
 drivers/gpu/drm/drm_edid.c  |3 
 drivers/gpu/drm/drm_edid_load.c |  147 
 firmware/Makefile   |7 
 firmware/edid/1024x768.S|   44 ++
 firmware/edid/1024x768.bin.ihex |9 +
 firmware/edid/1280x1024.S   |   44 ++
 firmware/edid/1280x1024.bin.ihex|9 +
 firmware/edid/1680x1050.S   |   44 ++
 firmware/edid/1680x1050.bin.ihex|9 +
 firmware/edid/1920x1080.S   |   44 ++
 firmware/edid/1920x1080.bin.ihex|9 +
 firmware/edid/edid.S|  261 
 include/drm/drm_crtc.h  |1 
 include/drm/drm_edid.h  |1 
 18 files changed, 657 insertions(+), 2 deletions(-)

Index: linux-3.3-rc6/Documentation/kernel-parameters.txt
===
--- linux-3.3-rc6.orig/Documentation/kernel-parameters.txt
+++ linux-3.3-rc6/Documentation/kernel-parameters.txt
@@ -713,6 +713,12 @@ bytes respectively. Such letter suffixes
The filter can be disabled or changed to another
driver later using sysfs.
 
+   drm_kms_helper.edid_firmware=
+   Broken monitors, graphic adapters and KVMs may
+   send no or broken EDID data sets. This parameter
+   allows to specify an EDID data set in the
+   /lib/firmware directory that is used instead.
+
dscc4.setup=[NET]
 
earlycon=   [KNL] Output early console device and options.
Index: linux-3.3-rc6/drivers/gpu/drm/Kconfig
===
--- linux-3.3-rc6.orig/drivers/gpu/drm/Kconfig
+++ linux-3.3-rc6/drivers/gpu/drm/Kconfig
@@ -27,6 +27,16 @@ config DRM_KMS_HELPER
help
  FB and CRTC helpers for KMS drivers.
 
+config DRM_LOAD_EDID_FIRMWARE
+   bool "Allow to load an EDID data set instead of probing it"
+   depends on DRM_KMS_HELPER
+   help
+ Say Y here, if you want to specify an EDID data blob to be
+ loaded from the /lib/firmware directory. This may be necessary,
+ if the graphics adapter or monitor are unable to provide
+ appropriate EDID data. Since this feature is provided as a
+ workaround for broken hardware, the default case is N.
+
 config DRM_TTM
tristate
depends on DRM
Index: linux-3.3-rc6/drivers/gpu/drm/Makefile
===
--- linux-3.3-rc6.orig/drivers/gpu/drm/Makefile
+++ linux-3.3-rc6/drivers/gpu/drm/Makefile
@@ -17,6 +17,9 @@ drm-y   :=drm_auth.o drm_buffer.o d
 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 
 drm_kms_helper-y := drm_fb_helper.o drm_crtc_helper.o drm_dp_i2c_helper.o
+ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
+drm_kms_helper-y += drm_edid_load.o
+endif
 
 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
 
Index: lin

Re: [PATCH 2/3] drivers-gpu-drm-add-disable-enable-connector.patch

[Carsten Emde]

On 03/11/2012 08:20 AM, Dave Airlie wrote:

On Sat, Mar 10, 2012 at 8:20 PM, Carsten Emde  wrote:

Some recent integrated graphics chipset, notably Intel's "Pineview", also
provide on-chip LVDS support. As an extra service, the LVDS interface supplies
EDID data - irrespective of whether an LVDS panel is connected or not. The
drm_mode_getresources() function, therefore, causes Xorg to always include
the LVDS panel into the display and initialize a separate screen for it. e.g.
(II) intel(0): Output LVDS1 connected
(II) intel(0): Output VGA1 connected
(II) intel(0): Using spanning desktop for initial modes
(II) intel(0): Output LVDS1 using initial mode 1024x768 +0+0
(II) intel(0): Output VGA1 using initial mode 1280x1024 +1024+0
which is not what you want, if the only connected screen is a VGA monitor.
One would assume that the BIOS settings of such systems would allow to
separately enable or disable LVDS support; unfortunately, systems have been
found in the wild that do not provide this feature.


So video=LVDS-1:d doesn't work for you?
Oops, yes, you are totally right. By some reason, I overlooked this 
option. I tried two systems that need forced disabling and enabling with

  video=LVDS-1:d video=VGA-1:e
which worked perfectly well.

So please skip this patch, sorry for the noise.

Thanks,
-Carsten.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

On 03/11/2012 02:44 PM, Alan Cox wrote:

This patch allows to load an EDID data set via the firmware interface.
It contains data sets of frequently used screen resolutions (1024x768,
1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
specified as a module parameter of the drm_kms_helper module, e.g.
options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
command line parameter.


What if the DRM layer and driver are compiled in. They'll come up as
console before the file system so the firmware request will hang ?
Admittedly I did not try to compile the DRM layer and driver into the 
kernel. However, I created an error condition by specifying a 
non-existing EDID file. In this case, the function returns with error, 
the mode count remains 0, and the system continues to run as if the 
edid_firmware= parameter had not been specified.


Now that you were asking, I created a static kernel and did some more 
tests, but I couldn't find any problem. Everything worked as expected. I 
believe that the early console still runs in BIOS VGA mode, i.e. either 
using the BIOS default mode or the one that was specified using the vga= 
parameter, if any. DRM apparently comes into play at a later stage only, 
but I will do some more testing.



Given the EDID is tiny and is data not code wouldn't it be simpler (and
smaller) if this option compiled in a few generic EDIDs to use ?
Yes, this certainly would be possible. However, we would loose the 
flexibility to specify an individual EDID data set without recompiling 
the kernel. As an alternative, we could compile the four standard EDIDs 
into the DRM helper instead of providing them as a file, but still leave 
the option to load an individual EDID via the firmware interface. This 
would make the patch much smaller and avoid spamming the firmware 
directory. How about that?


Thanks,
-Carsten.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

Alan,


This patch allows to load an EDID data set via the firmware interface.
It contains data sets of frequently used screen resolutions (1024x768,
1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
specified as a module parameter of the drm_kms_helper module, e.g.
options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
command line parameter.

[..]
Given the EDID is tiny and is data not code wouldn't it be simpler (and
smaller) if this option compiled in a few generic EDIDs to use ?
I liked the idea so much that I gave it a try. The patch looks much 
better now, but has the same functionality as before. As the only 
disadvantage, the patch no longer contains the template to produce a 
particular EDID. But this code may be made available elsewhere - no need 
to have it in the kernel.


Hope you like it.

Thanks,
-Carsten.
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  

The built-in data sets are
ResolutionName

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-/edid entry in the /sys/devices PCI directory
of a correctly working graphics adapter.

It is also 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 

---
 Documentation/kernel-parameters.txt |   10 +
 drivers/gpu/drm/Kconfig |   11 +
 drivers/gpu/drm/Makefile|3 
 drivers/gpu/drm/drm_crtc_helper.c   |8 +
 drivers/gpu/drm/drm_edid.c  |4 
 drivers/gpu/drm/drm_edid_load.c |  241 
 include/drm/drm_crtc.h  |1 
 include/drm/drm_edid.h  |1 
 8 files changed, 276 insertions(+), 3 deletions(-)

Index: linux-3.3-rc6/Documentation/kernel-parameters.txt
===
--- linux-3.3-rc6.orig/Documentation/kernel-parameters.txt
+++ linux-3.3-rc6/Documentation/kernel-parameters.txt
@@ -713,6 +713,16 @@ bytes respectively. Such letter suffixes
 			The filter can be disabled or changed to another
 			driver later using sysfs.
 
+	drm_kms_helper.edid_firmware=
+			Broken monitors, graphic adapters and KVMs may
+			send no or broken EDID data sets. This parameter
+			allows to specify an EDID data set in the
+			/lib/firmware directory that is used instead.
+			Generic built-in EDID data sets are used, if one of
+			edid/1024x768.bin, edid/1280x1024.bin,
+			edid/1680x1050.bin, or edid/1920x1080.bin is given
+			and no file with the same name exists.
+
 	dscc4.setup=	[NET]
 
 	earlycon=	[KNL] Output early console device and options.
Index: linux-3.3-rc6/drivers/gpu/drm/Kconfig
===
--- linux-3.3-rc6.orig/drivers/gpu/drm/Kconfig
+++ linux-3.3-rc6/drivers/gpu/drm/Kconfig
@@ -27,6 +27,17 @@ config DRM_KMS_HELPER
 	help
 	  FB and CRTC helpers for KMS drivers.
 
+config DRM_LOAD_EDID_FIRMWARE
+	bool "Allow to specify an EDID data set instead of probing for it"
+	depends on DRM_KMS_HELPER
+	help
+	  Say Y here, if you want to use EDID data to be loaded from the
+	  /lib/firmware directory or one of the provided built-in
+	  data sets. This may be necessary, if the graphics adapter or
+	  monitor are unable to provide appropriate EDID data. Since this
+	  feature is provided as a workaround for broken hardware, the
+	  default case is N.
+
 config DRM_TTM
 	tristate
 	depends on DRM
Index: linux-3.3-rc6/driver

[V2 PATCH 0/2] Provide workarounds to use DRM/KMS with broken graphics hardware

[Carsten Emde]

This is V2 of a patchset to use DRM/KMS with broken graphics hardware.

As a major change from V1, generic EDID data are now built-in into the
drm_kms_helper module as proposed by Alan. To help people building
their own EDID data and to understand how the binary EDID blobs in
drivers/gpu/drm/drm_edid_load.c have been created, the entire material
went into the Documentation tree as suggested by Valdis. Finally, David
showed a much better way to explicitly disable and enable a particular
connector, so patch 02/03 could go.

The two remaining patches
- introduce a mechanism to define or load EDID data instead of letting the
controller probe for it,
- add a parameter to the i915 module to invert the sense of the backlight
brightness variable for broken controllers that require this.

-Carsten.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[V2 PATCH 2/2] drivers-gpu-drm-i915-invert-backlight-brightness

[Carsten Emde]

Following the documentation of the Legacy Backlight Brightness (LBB)
Register in the configuration space of some Intel PCI graphics adapters,
setting the LBB register with the value 0x0 causes the backlight to be
turned off, and 0xFF causes the backlight to be set to 100% intensity
(http://download.intel.com/embedded/processors/Whitepaper/324567.pdf).
At least one of our test systems, however, turns the backlight off at
0xFF and sets it to maximum intensity at 0. In consequence, the screen
of this systems becomes dark at an early boot stage which makes it
unusable. The same inversion applies to the BLC_PWM_CTL I915 register.
This problem was introduced in kernel version 2.6.38 when the PCI device
of this system was first supported by the i915 KMS module.

This patch adds a module parameter to invert the backlight brightness
value before writing and after reading which makes the affected notebook
usable again.

Signed-off-by: Carsten Emde 

---
 Documentation/kernel-parameters.txt |9 +
 drivers/gpu/drm/i915/intel_panel.c  |   14 ++
 2 files changed, 23 insertions(+)

Index: linux-3.3-rc6/Documentation/kernel-parameters.txt
===
--- linux-3.3-rc6.orig/Documentation/kernel-parameters.txt
+++ linux-3.3-rc6/Documentation/kernel-parameters.txt
@@ -966,6 +966,15 @@ bytes respectively. Such letter suffixes
 
i810=   [HW,DRM]
 
+   i915.invert_brightness
+   [DRM] Invert the sense of the variable that is used to
+   set the brightness of the panel backlight. Normally a
+   value of 0 indicates backlight switched off, and the
+   maximum value sets the backlight to maximum brightness.
+   If this parameter is specified, a value of 0 sets the
+   backlight to maximum brightness, and the maximum value
+   switches the backlight off.
+
i8k.ignore_dmi  [HW] Continue probing hardware even if DMI data
indicates that the driver is running on unsupported
hardware.
Index: linux-3.3-rc6/drivers/gpu/drm/i915/intel_panel.c
===
--- linux-3.3-rc6.orig/drivers/gpu/drm/i915/intel_panel.c
+++ linux-3.3-rc6/drivers/gpu/drm/i915/intel_panel.c
@@ -28,6 +28,7 @@
  *  Chris Wilson 
  */
 
+#include 
 #include "intel_drv.h"
 
 #define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
@@ -191,6 +192,10 @@ u32 intel_panel_get_max_backlight(struct
return max;
 }
 
+static bool brightness_inverted;
+MODULE_PARM_DESC(brightness_inverted, "Backlight brightness value is inverted "
+   "(0 = max brightness, max value = dark)");
+module_param_named(brightness_inverted, brightness_inverted, bool, 0600);
 u32 intel_panel_get_backlight(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -212,6 +217,10 @@ u32 intel_panel_get_backlight(struct drm
}
 
DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
+   if (brightness_inverted) {
+   u32 max = intel_panel_get_max_backlight(dev);
+   val = max - val;
+   }
return val;
 }
 
@@ -229,6 +238,11 @@ static void intel_panel_actually_set_bac
 
DRM_DEBUG_DRIVER("set backlight PWM = %d\n", level);
 
+   if (brightness_inverted) {
+   u32 max = intel_panel_get_max_backlight(dev);
+   level = max - level;
+   }
+
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[V2 PATCH 1/2] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[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  

The built-in data sets are
ResolutionName

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-/edid entry in the /sys/devices PCI directory
of a correctly working graphics adapter.

It is also 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 

---
 Documentation/EDID/1024x768.S   |   44 ++
 Documentation/EDID/1280x1024.S  |   44 ++
 Documentation/EDID/1680x1050.S  |   44 ++
 Documentation/EDID/1920x1080.S  |   44 ++
 Documentation/EDID/HOWTO.txt|   39 +
 Documentation/EDID/Makefile |   25 +++
 Documentation/EDID/edid.S   |  261 
 Documentation/EDID/hex  |1 
 Documentation/kernel-parameters.txt |   10 +
 drivers/gpu/drm/Kconfig |   11 +
 drivers/gpu/drm/Makefile|3 
 drivers/gpu/drm/drm_crtc_helper.c   |8 -
 drivers/gpu/drm/drm_edid.c  |4 
 drivers/gpu/drm/drm_edid_load.c |  241 +
 include/drm/drm_crtc.h  |1 
 include/drm/drm_edid.h  |1 
 16 files changed, 778 insertions(+), 3 deletions(-)

Index: linux-3.3-rc6/Documentation/EDID/1024x768.S
===
--- /dev/null
+++ linux-3.3-rc6/Documentation/EDID/1024x768.S
@@ -0,0 +1,44 @@
+/*
+   1024x768.S: EDID data set for standard 1024x768 60 Hz monitor
+
+   Copyright (C) 2011 Carsten Emde 
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either version 2
+   of the License, or (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
+*/
+
+/* EDID */
+#define VERSION 1
+#define REVISION 3
+
+/* Display */
+#define CLOCK 65000 /* kHz */
+#define XPIX 1024
+#define YPIX 768
+#define XY_RATIO XY_RATIO_4_3
+#define XBLANK 320
+#define YBLANK 38
+#define XOFFSET 8
+#define XPULSE 144
+#define YOFFSET (63+3)
+#define YPULSE (63+6)
+#define DPI 72
+#define VFREQ 60 /* Hz */
+#define TIMING_NAME "Linux XGA"
+#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
+#define HSYNC_POL 0
+#define VSYNC_POL 0
+#define CRC 0x55
+
+#include "edid.S"
Index: linux-3.3-rc6/Documentation/EDID/1280x1024.S
===
--- /dev/null
+++ linux-3.3-rc6/Documentation/EDID/1280x1024.S
@@ -0,0 +1,44 @@
+/*
+   1280x1024.S: EDID data set for standard 1280x1024 60 Hz monitor
+
+   Copyright (C) 2011 Carsten Emde 
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either version 2
+   of the License, or (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without ev

[V3 PATCH 2/2] drivers-gpu-drm-i915-quirk-backlight-inverted.patch

[Carsten Emde]

Following the documentation of the Legacy Backlight Brightness (LBB)
Register in the configuration space of some Intel PCI graphics adapters,
setting the LBB register with the value 0x0 causes the backlight to be
turned off, and 0xFF causes the backlight to be set to 100% intensity
(http://download.intel.com/embedded/processors/Whitepaper/324567.pdf).
The Acer Aspire 5734Z, however, turns the backlight off at 0xFF and sets
it to maximum intensity at 0. In consequence, the screen of this systems
becomes dark at an early boot stage which makes it unusable. The same
inversion applies to the BLC_PWM_CTL I915 register. This problem was
introduced in kernel version 2.6.38 when the PCI device of this system
was first supported by the i915 KMS module.

This patch adds a quirk to invert the sense of the brightness variable
in case an Acer Aspire 5734Z is encountered.

Signed-off-by: Carsten Emde 

---
 drivers/gpu/drm/i915/i915_drv.h  |1 +
 drivers/gpu/drm/i915/intel_display.c |   12 
 drivers/gpu/drm/i915/intel_panel.c   |   10 ++
 3 files changed, 23 insertions(+)

Index: linux-3.3-rc7/drivers/gpu/drm/i915/i915_drv.h
===
--- linux-3.3-rc7.orig/drivers/gpu/drm/i915/i915_drv.h
+++ linux-3.3-rc7/drivers/gpu/drm/i915/i915_drv.h
@@ -275,6 +275,7 @@ enum intel_pch {
 
 #define QUIRK_PIPEA_FORCE (1<<0)
 #define QUIRK_LVDS_SSC_DISABLE (1<<1)
+#define QUIRK_BRIGHTNESS_INVERTED (1<<2)
 
 struct intel_fbdev;
 struct intel_fbc_work;
Index: linux-3.3-rc7/drivers/gpu/drm/i915/intel_display.c
===
--- linux-3.3-rc7.orig/drivers/gpu/drm/i915/intel_display.c
+++ linux-3.3-rc7/drivers/gpu/drm/i915/intel_display.c
@@ -8950,6 +8950,15 @@ static void quirk_ssc_force_disable(stru
dev_priv->quirks |= QUIRK_LVDS_SSC_DISABLE;
 }
 
+/*
+ * At least one machine (Acer Aspire 5734Z) has inverted backlight brightness
+ */
+static void quirk_brightness_inverted(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   dev_priv->quirks |= QUIRK_BRIGHTNESS_INVERTED;
+}
+
 struct intel_quirk {
int device;
int subsystem_vendor;
@@ -8984,6 +8993,9 @@ struct intel_quirk intel_quirks[] = {
 
/* Sony Vaio Y cannot use SSC on LVDS */
{ 0x0046, 0x104d, 0x9076, quirk_ssc_force_disable },
+
+   /* Acer Aspire 5734Z has inverted backlight brightness */
+   { 0x2a42, 0x1025, 0x0459, quirk_brightness_inverted },
 };
 
 static void intel_init_quirks(struct drm_device *dev)
Index: linux-3.3-rc7/drivers/gpu/drm/i915/intel_panel.c
===
--- linux-3.3-rc7.orig/drivers/gpu/drm/i915/intel_panel.c
+++ linux-3.3-rc7/drivers/gpu/drm/i915/intel_panel.c
@@ -28,6 +28,7 @@
  *  Chris Wilson 
  */
 
+#include 
 #include "intel_drv.h"
 
 #define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
@@ -212,6 +213,10 @@ u32 intel_panel_get_backlight(struct drm
}
 
DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
+   if (dev_priv->quirks & QUIRK_BRIGHTNESS_INVERTED) {
+   u32 max = intel_panel_get_max_backlight(dev);
+   val = max - val;
+   }
return val;
 }
 
@@ -229,6 +234,11 @@ static void intel_panel_actually_set_bac
 
DRM_DEBUG_DRIVER("set backlight PWM = %d\n", level);
 
+   if (dev_priv->quirks & QUIRK_BRIGHTNESS_INVERTED) {
+   u32 max = intel_panel_get_max_backlight(dev);
+   level = max - level;
+   }
+
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);
 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[V3 PATCH 1/2] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[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  

The built-in data sets are
ResolutionName

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-/edid entry in the /sys/devices PCI directory
of a correctly working graphics adapter.

It is also 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 

---
 Documentation/EDID/1024x768.S   |   44 ++
 Documentation/EDID/1280x1024.S  |   44 ++
 Documentation/EDID/1680x1050.S  |   44 ++
 Documentation/EDID/1920x1080.S  |   44 ++
 Documentation/EDID/HOWTO.txt|   39 +
 Documentation/EDID/Makefile |   26 +++
 Documentation/EDID/edid.S   |  261 
 Documentation/EDID/hex  |1 
 Documentation/kernel-parameters.txt |   12 +
 drivers/gpu/drm/Kconfig |   12 +
 drivers/gpu/drm/Makefile|3 
 drivers/gpu/drm/drm_crtc_helper.c   |8 -
 drivers/gpu/drm/drm_edid.c  |4 
 drivers/gpu/drm/drm_edid_load.c |  241 +
 include/drm/drm_crtc.h  |1 
 include/drm/drm_edid.h  |1 
 16 files changed, 782 insertions(+), 3 deletions(-)

Index: linux-3.3-rc7/Documentation/EDID/1024x768.S
===
--- /dev/null
+++ linux-3.3-rc7/Documentation/EDID/1024x768.S
@@ -0,0 +1,44 @@
+/*
+   1024x768.S: EDID data set for standard 1024x768 60 Hz monitor
+
+   Copyright (C) 2011 Carsten Emde 
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either version 2
+   of the License, or (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
+*/
+
+/* EDID */
+#define VERSION 1
+#define REVISION 3
+
+/* Display */
+#define CLOCK 65000 /* kHz */
+#define XPIX 1024
+#define YPIX 768
+#define XY_RATIO XY_RATIO_4_3
+#define XBLANK 320
+#define YBLANK 38
+#define XOFFSET 8
+#define XPULSE 144
+#define YOFFSET (63+3)
+#define YPULSE (63+6)
+#define DPI 72
+#define VFREQ 60 /* Hz */
+#define TIMING_NAME "Linux XGA"
+#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
+#define HSYNC_POL 0
+#define VSYNC_POL 0
+#define CRC 0x55
+
+#include "edid.S"
Index: linux-3.3-rc7/Documentation/EDID/1280x1024.S
===
--- /dev/null
+++ linux-3.3-rc7/Documentation/EDID/1280x1024.S
@@ -0,0 +1,44 @@
+/*
+   1280x1024.S: EDID data set for standard 1280x1024 60 Hz monitor
+
+   Copyright (C) 2011 Carsten Emde 
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either version 2
+   of the License, or (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without ev

Re: [V3 PATCH 1/2] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

Bastien,


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


Windows allow vendor to override eddid based on 3 bytes manufacturer
and product code.

This may solve the situation when a particular monitor lies about the
required setting or its EDID data set has an invalid CRC. However, this
does not solve the situation when we do not get any useful EDID
information, because something is totally broken. This also applies to
the KVM situation when the KVM sends EDID data that are totally
unrelated to the monitor at the other side of the KVM.


Seems a reasonnable approach to follow.

I am not yet convinced.

-Carsten.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[V3 PATCH 0/2] Provide workarounds to use DRM/KMS with broken graphics hardware

[Carsten Emde]

Changes from V2 to V3:

1. The help text of the DRM_LOAD_EDID_FIRMWARE Kconfig item and the
related explanation in Documentation/kernel-parameters.txt now contain
a pointer to the documentation as suggested by Paul.
2. Removed the "brightness_inverted" parameter of the i915 module and
replaced it by a quirk that is specific to the affected Acer Aspire 5734Z
notebook as suggested by Keith.

Thanks,
-Carsten.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[V4 PATCH 0/2] Provide workarounds to use DRM/KMS with broken graphics hardware

[Carsten Emde]

Changes from V3 to V4:

Reverted the removal of the "brightness_inverted" parameter of the i915
module as suggested by Chris. Inversion of the sense of the brightness
variable is now enabled, if either the quirked notebook is encountered
or the "brightness_inverted" module parameter switch is set.

Thanks,
-Carsten.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[V4 PATCH 2/2] drivers-gpu-drm-i915-backlight-brightness-inverted.patch

[Carsten Emde]

Following the documentation of the Legacy Backlight Brightness (LBB)
Register in the configuration space of some Intel PCI graphics adapters,
setting the LBB register with the value 0x0 causes the backlight to be
turned off, and 0xFF causes the backlight to be set to 100% intensity
(http://download.intel.com/embedded/processors/Whitepaper/324567.pdf).
The Acer Aspire 5734Z, however, turns the backlight off at 0xFF and sets
it to maximum intensity at 0. In consequence, the screen of this systems
becomes dark at an early boot stage which makes it unusable. The same
inversion applies to the BLC_PWM_CTL I915 register. This problem was
introduced in kernel version 2.6.38 when the PCI device of this system
was first supported by the i915 KMS module.

This patch adds a quirk to invert the sense of the brightness variable
in case an Acer Aspire 5734Z is encountered.

In addition, there is now a parameter of the i915 module to enable
inversion of the brightness variable (i915 brightness_inverted).

Signed-off-by: Carsten Emde 

---
 Documentation/kernel-parameters.txt  |9 +
 drivers/gpu/drm/i915/i915_drv.h  |1 +
 drivers/gpu/drm/i915/intel_display.c |   12 
 drivers/gpu/drm/i915/intel_panel.c   |   16 
 4 files changed, 38 insertions(+)

Index: linux-3.3-rc7/Documentation/kernel-parameters.txt
===
--- linux-3.3-rc7.orig/Documentation/kernel-parameters.txt
+++ linux-3.3-rc7/Documentation/kernel-parameters.txt
@@ -979,6 +979,15 @@ bytes respectively. Such letter suffixes
i8k.restricted  [HW] Allow controlling fans only if SYS_ADMIN
capability is set.
 
+   i915.brightness_inverted
+   [DRM] Invert the sense of the variable that is used to
+   set the brightness of the panel backlight. Normally a
+   value of 0 indicates backlight switched off, and the
+   maximum value sets the backlight to maximum brightness.
+   If this parameter is specified, a value of 0 sets the
+   backlight to maximum brightness, and the maximum value
+   switches the backlight off.
+
icn=[HW,ISDN]
Format: [,[,[,]]]
 
Index: linux-3.3-rc7/drivers/gpu/drm/i915/i915_drv.h
===
--- linux-3.3-rc7.orig/drivers/gpu/drm/i915/i915_drv.h
+++ linux-3.3-rc7/drivers/gpu/drm/i915/i915_drv.h
@@ -275,6 +275,7 @@ enum intel_pch {
 
 #define QUIRK_PIPEA_FORCE (1<<0)
 #define QUIRK_LVDS_SSC_DISABLE (1<<1)
+#define QUIRK_BRIGHTNESS_INVERTED (1<<2)
 
 struct intel_fbdev;
 struct intel_fbc_work;
Index: linux-3.3-rc7/drivers/gpu/drm/i915/intel_display.c
===
--- linux-3.3-rc7.orig/drivers/gpu/drm/i915/intel_display.c
+++ linux-3.3-rc7/drivers/gpu/drm/i915/intel_display.c
@@ -8950,6 +8950,15 @@ static void quirk_ssc_force_disable(stru
dev_priv->quirks |= QUIRK_LVDS_SSC_DISABLE;
 }
 
+/*
+ * At least one machine (Acer Aspire 5734Z) has inverted backlight brightness
+ */
+static void quirk_brightness_inverted(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   dev_priv->quirks |= QUIRK_BRIGHTNESS_INVERTED;
+}
+
 struct intel_quirk {
int device;
int subsystem_vendor;
@@ -8984,6 +8993,9 @@ struct intel_quirk intel_quirks[] = {
 
/* Sony Vaio Y cannot use SSC on LVDS */
{ 0x0046, 0x104d, 0x9076, quirk_ssc_force_disable },
+
+   /* Acer Aspire 5734Z has inverted backlight brightness */
+   { 0x2a42, 0x1025, 0x0459, quirk_brightness_inverted },
 };
 
 static void intel_init_quirks(struct drm_device *dev)
Index: linux-3.3-rc7/drivers/gpu/drm/i915/intel_panel.c
===
--- linux-3.3-rc7.orig/drivers/gpu/drm/i915/intel_panel.c
+++ linux-3.3-rc7/drivers/gpu/drm/i915/intel_panel.c
@@ -28,6 +28,7 @@
  *  Chris Wilson 
  */
 
+#include 
 #include "intel_drv.h"
 
 #define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
@@ -191,6 +192,10 @@ u32 intel_panel_get_max_backlight(struct
return max;
 }
 
+static bool brightness_inverted;
+MODULE_PARM_DESC(brightness_inverted, "Backlight brightness value is inverted "
+   "(0 = max brightness, max value = backlight switched off)");
+module_param_named(brightness_inverted, brightness_inverted, bool, 0600);
 u32 intel_panel_get_backlight(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -212,6 +217,11 @@ u32 intel_panel_get_backlight(struct drm
}
 
DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
+   if ((dev_priv->quirks & QUIRK_BRIGHTNESS_INVERTED) ||
+   brigh

[V4 PATCH 1/2] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[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  

The built-in data sets are
ResolutionName

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-/edid entry in the /sys/devices PCI directory
of a correctly working graphics adapter.

It is also 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 

---
 Documentation/EDID/1024x768.S   |   44 ++
 Documentation/EDID/1280x1024.S  |   44 ++
 Documentation/EDID/1680x1050.S  |   44 ++
 Documentation/EDID/1920x1080.S  |   44 ++
 Documentation/EDID/HOWTO.txt|   39 +
 Documentation/EDID/Makefile |   26 +++
 Documentation/EDID/edid.S   |  261 
 Documentation/EDID/hex  |1 
 Documentation/kernel-parameters.txt |   12 +
 drivers/gpu/drm/Kconfig |   12 +
 drivers/gpu/drm/Makefile|3 
 drivers/gpu/drm/drm_crtc_helper.c   |8 -
 drivers/gpu/drm/drm_edid.c  |4 
 drivers/gpu/drm/drm_edid_load.c |  241 +
 include/drm/drm_crtc.h  |1 
 include/drm/drm_edid.h  |1 
 16 files changed, 782 insertions(+), 3 deletions(-)

Index: linux-3.3-rc7/Documentation/EDID/1024x768.S
===
--- /dev/null
+++ linux-3.3-rc7/Documentation/EDID/1024x768.S
@@ -0,0 +1,44 @@
+/*
+   1024x768.S: EDID data set for standard 1024x768 60 Hz monitor
+
+   Copyright (C) 2011 Carsten Emde 
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either version 2
+   of the License, or (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
+*/
+
+/* EDID */
+#define VERSION 1
+#define REVISION 3
+
+/* Display */
+#define CLOCK 65000 /* kHz */
+#define XPIX 1024
+#define YPIX 768
+#define XY_RATIO XY_RATIO_4_3
+#define XBLANK 320
+#define YBLANK 38
+#define XOFFSET 8
+#define XPULSE 144
+#define YOFFSET (63+3)
+#define YPULSE (63+6)
+#define DPI 72
+#define VFREQ 60 /* Hz */
+#define TIMING_NAME "Linux XGA"
+#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
+#define HSYNC_POL 0
+#define VSYNC_POL 0
+#define CRC 0x55
+
+#include "edid.S"
Index: linux-3.3-rc7/Documentation/EDID/1280x1024.S
===
--- /dev/null
+++ linux-3.3-rc7/Documentation/EDID/1280x1024.S
@@ -0,0 +1,44 @@
+/*
+   1280x1024.S: EDID data set for standard 1280x1024 60 Hz monitor
+
+   Copyright (C) 2011 Carsten Emde 
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either version 2
+   of the License, or (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without ev

[V5 PATCH 0/4] Provide workarounds to use DRM/KMS with broken graphics hardware

[Carsten Emde]

Changes from V4 to V5:

1. Split the previous patch 2/2 into three patches to separately i) add the
module parameter, ii) add the quirk infrastructure, and iii) actually quirk
the related machine.

2. Rename the module parameter variable to i915_panel_invert_brightness.

3. Make the module parameter variable tristate to either ignore the
quirk, consider the quirk, if any, or force inversion.

4. Print an instruction along the description of the module parameter to
encourage people sending machine data, should another machine be found
that needs to be quirked.

5. Introduce the function intel_panel_compute_brightness where the
brightness calculation is handled.

Thanks, Chris, for these very valuable suggestions.

-Carsten.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[V5 PATCH 1/4] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[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  

The built-in data sets are
ResolutionName

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-/edid entry in the /sys/devices PCI directory
of a correctly working graphics adapter.

It is also 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 

---
 Documentation/EDID/1024x768.S   |   44 ++
 Documentation/EDID/1280x1024.S  |   44 ++
 Documentation/EDID/1680x1050.S  |   44 ++
 Documentation/EDID/1920x1080.S  |   44 ++
 Documentation/EDID/HOWTO.txt|   39 +
 Documentation/EDID/Makefile |   26 +++
 Documentation/EDID/edid.S   |  261 
 Documentation/EDID/hex  |1 
 Documentation/kernel-parameters.txt |   12 +
 drivers/gpu/drm/Kconfig |   12 +
 drivers/gpu/drm/Makefile|3 
 drivers/gpu/drm/drm_crtc_helper.c   |8 -
 drivers/gpu/drm/drm_edid.c  |4 
 drivers/gpu/drm/drm_edid_load.c |  241 +
 include/drm/drm_crtc.h  |1 
 include/drm/drm_edid.h  |1 
 16 files changed, 782 insertions(+), 3 deletions(-)

Index: linux-3.3-rc7/Documentation/EDID/1024x768.S
===
--- /dev/null
+++ linux-3.3-rc7/Documentation/EDID/1024x768.S
@@ -0,0 +1,44 @@
+/*
+   1024x768.S: EDID data set for standard 1024x768 60 Hz monitor
+
+   Copyright (C) 2011 Carsten Emde 
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either version 2
+   of the License, or (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
+*/
+
+/* EDID */
+#define VERSION 1
+#define REVISION 3
+
+/* Display */
+#define CLOCK 65000 /* kHz */
+#define XPIX 1024
+#define YPIX 768
+#define XY_RATIO XY_RATIO_4_3
+#define XBLANK 320
+#define YBLANK 38
+#define XOFFSET 8
+#define XPULSE 144
+#define YOFFSET (63+3)
+#define YPULSE (63+6)
+#define DPI 72
+#define VFREQ 60 /* Hz */
+#define TIMING_NAME "Linux XGA"
+#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
+#define HSYNC_POL 0
+#define VSYNC_POL 0
+#define CRC 0x55
+
+#include "edid.S"
Index: linux-3.3-rc7/Documentation/EDID/1280x1024.S
===
--- /dev/null
+++ linux-3.3-rc7/Documentation/EDID/1280x1024.S
@@ -0,0 +1,44 @@
+/*
+   1280x1024.S: EDID data set for standard 1280x1024 60 Hz monitor
+
+   Copyright (C) 2011 Carsten Emde 
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either version 2
+   of the License, or (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without ev

[V5 PATCH 4/4] drivers-gpu-drm-i915-panel-invert-brightness-acer-aspire-5734z.patch

[Carsten Emde]

Mark the Acer Aspire 5734Z that this machines requires the module to
invert the panel backlight brightness value after reading from and prior
to writing to the PCI configuration space.

Signed-off-by: Carsten Emde 

---
 drivers/gpu/drm/i915/intel_display.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

Index: linux-3.3-rc7/drivers/gpu/drm/i915/intel_display.c
===
--- linux-3.3-rc7.orig/drivers/gpu/drm/i915/intel_display.c
+++ linux-3.3-rc7/drivers/gpu/drm/i915/intel_display.c
@@ -8951,7 +8951,8 @@ static void quirk_ssc_force_disable(stru
 }
 
 /*
- * A machine may need to invert the panel backlight brightness value
+ * A machine (e.g. Acer Aspire 5734Z) may need to invert the panel backlight
+ * brightness value
  */
 static void quirk_invert_brightness(struct drm_device *dev)
 {
@@ -8993,6 +8994,9 @@ struct intel_quirk intel_quirks[] = {
 
/* Sony Vaio Y cannot use SSC on LVDS */
{ 0x0046, 0x104d, 0x9076, quirk_ssc_force_disable },
+
+   /* Acer Aspire 5734Z must invert backlight brightness */
+   { 0x2a42, 0x1025, 0x0459, quirk_invert_brightness },
 };
 
 static void intel_init_quirks(struct drm_device *dev)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[V5 PATCH 3/4] drivers-gpu-drm-i915-panel-invert-brightness-via-quirk.patch

[Carsten Emde]

A machine may need to invert the panel backlight brightness value. This
patch adds the infrastructure for a quirk to do so.

Signed-off-by: Carsten Emde 

---
 Documentation/kernel-parameters.txt  |   17 +++--
 drivers/gpu/drm/i915/i915_drv.h  |1 +
 drivers/gpu/drm/i915/intel_display.c |9 +
 drivers/gpu/drm/i915/intel_panel.c   |   15 +++
 4 files changed, 32 insertions(+), 10 deletions(-)

Index: linux-3.3-rc7/Documentation/kernel-parameters.txt
===
--- linux-3.3-rc7.orig/Documentation/kernel-parameters.txt
+++ linux-3.3-rc7/Documentation/kernel-parameters.txt
@@ -979,14 +979,19 @@ bytes respectively. Such letter suffixes
i8k.restricted  [HW] Allow controlling fans only if SYS_ADMIN
capability is set.
 
-   i915.invert_brightness
+   i915.invert_brightness=
[DRM] Invert the sense of the variable that is used to
set the brightness of the panel backlight. Normally a
-   value of 0 indicates backlight switched off, and the
-   maximum value sets the backlight to maximum brightness.
-   If this parameter is specified, a value of 0 sets the
-   backlight to maximum brightness, and the maximum value
-   switches the backlight off.
+   brightness value of 0 indicates backlight switched off,
+   and the maximum of the brightness value sets the 
backlight
+   to maximum brightness. If this parameter is set to 0
+   (default) and the machine requires it, or this parameter
+   is set to 1, a brightness value of 0 sets the backlight
+   to maximum brightness, and the maximum of the brightness
+   value switches the backlight off.
+   -1 -- never invert brightness
+0 -- machine default
+1 -- force brightness inversion
 
icn=[HW,ISDN]
Format: [,[,[,]]]
Index: linux-3.3-rc7/drivers/gpu/drm/i915/i915_drv.h
===
--- linux-3.3-rc7.orig/drivers/gpu/drm/i915/i915_drv.h
+++ linux-3.3-rc7/drivers/gpu/drm/i915/i915_drv.h
@@ -275,6 +275,7 @@ enum intel_pch {
 
 #define QUIRK_PIPEA_FORCE (1<<0)
 #define QUIRK_LVDS_SSC_DISABLE (1<<1)
+#define QUIRK_INVERT_BRIGHTNESS (1<<2)
 
 struct intel_fbdev;
 struct intel_fbc_work;
Index: linux-3.3-rc7/drivers/gpu/drm/i915/intel_display.c
===
--- linux-3.3-rc7.orig/drivers/gpu/drm/i915/intel_display.c
+++ linux-3.3-rc7/drivers/gpu/drm/i915/intel_display.c
@@ -8950,6 +8950,15 @@ static void quirk_ssc_force_disable(stru
dev_priv->quirks |= QUIRK_LVDS_SSC_DISABLE;
 }
 
+/*
+ * A machine may need to invert the panel backlight brightness value
+ */
+static void quirk_invert_brightness(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   dev_priv->quirks |= QUIRK_INVERT_BRIGHTNESS;
+}
+
 struct intel_quirk {
int device;
int subsystem_vendor;
Index: linux-3.3-rc7/drivers/gpu/drm/i915/intel_panel.c
===
--- linux-3.3-rc7.orig/drivers/gpu/drm/i915/intel_panel.c
+++ linux-3.3-rc7/drivers/gpu/drm/i915/intel_panel.c
@@ -192,15 +192,22 @@ u32 intel_panel_get_max_backlight(struct
return max;
 }
 
-static bool i915_panel_invert_brightness;
-MODULE_PARM_DESC(invert_brightness, "Invert backlight brightness, please "
+static int i915_panel_invert_brightness;
+MODULE_PARM_DESC(invert_brightness, "Invert backlight brightness "
+   "(-1 force normal, 0 machine defaults, 1 force inversion), please "
"report PCI device ID, subsystem vendor and subsystem device ID "
"to dri-devel@lists.freedesktop.org, if your machine needs it. "
"It will then be included in an upcoming module version.");
-module_param_named(invert_brightness, i915_panel_invert_brightness, bool, 
0600);
+module_param_named(invert_brightness, i915_panel_invert_brightness, int, 0600);
 static u32 intel_panel_compute_brightness(struct drm_device *dev, u32 val)
 {
-   if (i915_panel_invert_brightness)
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   if (i915_panel_invert_brightness < 0)
+   return val;
+
+   if (i915_panel_invert_brightness > 0 ||
+   dev_priv->quirks & QUIRK_INVERT_BRIGHTNESS)
return intel_panel_get_max_backlight(dev) - val;
 
return val;

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[V5 PATCH 2/4] drivers-gpu-drm-i915-panel-invert-brightness-via-parameter.patch

[Carsten Emde]

Following the documentation of the Legacy Backlight Brightness (LBB)
Register in the configuration space of some Intel PCI graphics adapters,
setting the LBB register with the value 0x0 causes the backlight to be
turned off, and 0xFF causes the backlight to be set to 100% intensity
(http://download.intel.com/embedded/processors/Whitepaper/324567.pdf).
The Acer Aspire 5734Z, however, turns the backlight off at 0xFF and sets
it to maximum intensity at 0. In consequence, the screen of this systems
becomes dark at an early boot stage which makes it unusable. The same
inversion applies to the BLC_PWM_CTL I915 register. This problem was
introduced in kernel version 2.6.38 when the PCI device of this system
was first supported by the i915 KMS module.

This patch adds a parameter to the i915 module to enable inversion of
the brightness variable (i915.invert_brightness).

Signed-off-by: Carsten Emde 

---
 Documentation/kernel-parameters.txt |9 +
 drivers/gpu/drm/i915/intel_panel.c  |   17 +
 2 files changed, 26 insertions(+)

Index: linux-3.3-rc7/Documentation/kernel-parameters.txt
===
--- linux-3.3-rc7.orig/Documentation/kernel-parameters.txt
+++ linux-3.3-rc7/Documentation/kernel-parameters.txt
@@ -979,6 +979,15 @@ bytes respectively. Such letter suffixes
i8k.restricted  [HW] Allow controlling fans only if SYS_ADMIN
capability is set.
 
+   i915.invert_brightness
+   [DRM] Invert the sense of the variable that is used to
+   set the brightness of the panel backlight. Normally a
+   value of 0 indicates backlight switched off, and the
+   maximum value sets the backlight to maximum brightness.
+   If this parameter is specified, a value of 0 sets the
+   backlight to maximum brightness, and the maximum value
+   switches the backlight off.
+
icn=[HW,ISDN]
Format: [,[,[,]]]
 
Index: linux-3.3-rc7/drivers/gpu/drm/i915/intel_panel.c
===
--- linux-3.3-rc7.orig/drivers/gpu/drm/i915/intel_panel.c
+++ linux-3.3-rc7/drivers/gpu/drm/i915/intel_panel.c
@@ -28,6 +28,7 @@
  *  Chris Wilson 
  */
 
+#include 
 #include "intel_drv.h"
 
 #define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
@@ -191,6 +192,20 @@ u32 intel_panel_get_max_backlight(struct
return max;
 }
 
+static bool i915_panel_invert_brightness;
+MODULE_PARM_DESC(invert_brightness, "Invert backlight brightness, please "
+   "report PCI device ID, subsystem vendor and subsystem device ID "
+   "to dri-devel@lists.freedesktop.org, if your machine needs it. "
+   "It will then be included in an upcoming module version.");
+module_param_named(invert_brightness, i915_panel_invert_brightness, bool, 
0600);
+static u32 intel_panel_compute_brightness(struct drm_device *dev, u32 val)
+{
+   if (i915_panel_invert_brightness)
+   return intel_panel_get_max_backlight(dev) - val;
+
+   return val;
+}
+
 u32 intel_panel_get_backlight(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -211,6 +226,7 @@ u32 intel_panel_get_backlight(struct drm
}
}
 
+   val = intel_panel_compute_brightness(dev, val);
DRM_DEBUG_DRIVER("get backlight PWM = %d\n", val);
return val;
 }
@@ -228,6 +244,7 @@ static void intel_panel_actually_set_bac
u32 tmp;
 
DRM_DEBUG_DRIVER("set backlight PWM = %d\n", level);
+   level = intel_panel_compute_brightness(dev, level);
 
if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [V5 PATCH 1/4] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

Dear Thomas,


your proposal will not lead to a satisfying solution for those people
that suffer from monitors and other HW devices that provide wrong
EDIDs.

Oops, why not?


Before fetching the display modes, all drm devices will try to detect
the monitor. If EDID data is not correct (checksum), an error
notification including an EDID dump will be stored in the logs.
Depending on the driver (Intel, Radeon, ...) a wrong EDID during
detection may prevent the further use of the connector until
detection of a valid EDID.

Yes - until detection of a valid EDID. Specifying the "edid_firmware="
module parameter leads to the detection of a valid EDID and then
everything works - at least, if the specified EDID data is valid. This
works pretty well in more than 15 systems that I tested - admittedly
only Intel and Radeon but many different adapters, monitors and reasons
for misbehavior. Did you try the patch? If so, which graphics adapter
did you try? It is well possible that I overlooked a detail that is not
relevant in the adapters that I tested. Please let me know so I can fix it.


Furthermore, all current graphic adapters provide at least three and
 even more connectors. Many people use two monitors in parallel.

This is a good point. I will provide a new version of the patch that
allows to alternatively prepend the connector name to the name of the
EDID firmware separated by a colon such as
  edid_firmware=[:]


If I understand your patch correctly, it would load EDID defaults
for all connectors and all monitors, despite of their EDID being
correct or wrong.

For all connectors with a monitor connected to it, yes. It is impossible
to always decide whether a particular EDID data set is wrong or not. It
may, for example, have a correct CRC but still lie to the connector
about other things such as sync polarity.


What about audio parameters for HDMI connectors?

Not yet considered.


On the other hand, there are still KVM switches and monitors out that
would work correctly. but provide an incorrect, not usuable EDID. If
we focus the default EDID loading on the buggy EDIDs over a working
(!) connector, I could imagine a benefit for all users.

Again, this is not possible. Only a human being sitting in front of a
monitor can decide whether a particular EDID data set works or not.

The upcoming version that allows to specify the connector name for a
given EDID firmware probably will solve this situation. If you specify
the EDID firmware for the connector only to which the broken monitor is
connected, the other connectors will not be affected.

Thanks,
-Carsten.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[V6 PATCH 0/1] Provide workarounds to use DRM/KMS with broken graphics hardware

[Carsten Emde]

Changes from V5 to V6:

1. The use of a particular EDID data set can now be restricted to a
given connector using the syntax
  edid_firmware=[:]
as suggested by Thomas Reim.

2. The patches to introduce a module parameter and a quirk to cope with
an inverted brightness variable of some i915 graphics adapters are no
longer part of this patch series.

Thanks,
Carsten.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[V6 PATCH 1/1] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[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=[:]
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
ResolutionName

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-/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 

---
 Documentation/EDID/1024x768.S   |   44 ++
 Documentation/EDID/1280x1024.S  |   44 ++
 Documentation/EDID/1680x1050.S  |   44 ++
 Documentation/EDID/1920x1080.S  |   44 ++
 Documentation/EDID/HOWTO.txt|   39 +
 Documentation/EDID/Makefile |   26 +++
 Documentation/EDID/edid.S   |  261 
 Documentation/EDID/hex  |1 
 Documentation/kernel-parameters.txt |   15 ++
 drivers/gpu/drm/Kconfig |   12 +
 drivers/gpu/drm/Makefile|3 
 drivers/gpu/drm/drm_crtc_helper.c   |8 -
 drivers/gpu/drm/drm_edid.c  |4 
 drivers/gpu/drm/drm_edid_load.c |  250 ++
 include/drm/drm_crtc.h  |1 
 include/drm/drm_edid.h  |1 
 16 files changed, 794 insertions(+), 3 deletions(-)

Index: linux-3.3-rc7/Documentation/EDID/1024x768.S
===
--- /dev/null
+++ linux-3.3-rc7/Documentation/EDID/1024x768.S
@@ -0,0 +1,44 @@
+/*
+   1024x768.S: EDID data set for standard 1024x768 60 Hz monitor
+
+   Copyright (C) 2011 Carsten Emde 
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either version 2
+   of the License, or (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
+*/
+
+/* EDID */
+#define VERSION 1
+#define REVISION 3
+
+/* Display */
+#define CLOCK 65000 /* kHz */
+#define XPIX 1024
+#define YPIX 768
+#define XY_RATIO XY_RATIO_4_3
+#define XBLANK 320
+#define YBLANK 38
+#define XOFFSET 8
+#define XPULSE 144
+#define YOFFSET (63+3)
+#define YPULSE (63+6)
+#define DPI 72
+#define VFREQ 60 /* Hz */
+#define TIMING_NAME "Linux XGA"
+#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
+#define HSYNC_POL 0
+#define VSYNC_POL 0
+#define CRC 0x55
+
+#include "edid.S"
Index: linux-3.3-rc7/Documentation/EDID/1280x1024.S
===
--- /dev/null
+++ linux-3.3-rc7/Documentation/EDID/1280x1024.S
@@ -0,0 +1,44 @@
+/*
+   1280x1024.S: EDID data set for standard 1280x1024 60 Hz monitor
+
+   Copyright (C) 2011 Carsten Emde 
+
+   This program is free softwar

Re: [PATCH 1/3] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

Michael,


On Sun, 11 Mar 2012 22:23:22 +0100, Carsten Emde wrote:

On 03/11/2012 02:44 PM, Alan Cox wrote:

This patch allows to load an EDID data set via the firmware interface.
It contains data sets of frequently used screen resolutions (1024x768,
1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
specified as a module parameter of the drm_kms_helper module, e.g.
options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
command line parameter.

What if the DRM layer and driver are compiled in. They'll come up as
console before the file system so the firmware request will hang ?

Admittedly I did not try to compile the DRM layer and driver into the
kernel. However, I created an error condition by specifying a
non-existing EDID file. In this case, the function returns with error,
the mode count remains 0, and the system continues to run as if the
edid_firmware= parameter had not been specified.

Unfortunately, as of at least last month, my system hangs when I try to
use your feature (just as described by Alan Cox); the log shows that
during the boot process, there is a one-minute hang:

   [0.175207] [drm] radeon: power management initialized
   [   60.896507] [drm:edid_load] *ERROR* Requesting EDID firmware 
"edid/1920x1200.bin" failed (err=-2)

Is there any way to make your feature smarter about its timing with
relation to file system accessibility?

Sure.

Please copy your EDID data file to the directory "firmware/edid" of the 
kernel source tree, configure


CONFIG_EXTRA_FIRMWARE="edid/1920x1200.bin"
CONFIG_EXTRA_FIRMWARE_DIR="firmware"

and rebuild/reboot your kernel.

Does it work then?

-Carsten.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/1] Improve documentation to create an EDID data set

[Carsten Emde]

Among the (predominantly positive) feedback to the EDID firmware loader
(http://lists.freedesktop.org/archives/dri-devel/2012-March/020292.html),
there was a complaint that the documentation could be clearer how to
create a particular EDID data set from timing data in X11 format.

This patch adds a related section to the documentation. 

-Carsten. 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/1] Load EDID: Explain better how to write your own EDID firmware

[Carsten Emde]

A description was lacking how to write an EDID firmware file that
corresponds to a given X11 setting.

Signed-off-by: Carsten Emde 

---
 Documentation/EDID/HOWTO.txt |   27 +++
 1 file changed, 23 insertions(+), 4 deletions(-)

Index: linux-3.4.4-rt13/Documentation/EDID/HOWTO.txt
===
--- linux-3.4.4-rt13.orig/Documentation/EDID/HOWTO.txt
+++ linux-3.4.4-rt13/Documentation/EDID/HOWTO.txt
@@ -28,11 +28,30 @@ Makefile environment are given here.
 To create binary EDID and C source code files from the existing data
 material, simply type "make".
 
-If you want to create your own EDID file, copy the file 1024x768.S and
-replace the settings with your own data. The CRC value in the last line
+If you want to create your own EDID file, copy the file 1024x768.S,
+replace the settings with your own data and add a new target to the
+Makefile. Please note that the EDID data structure expects the timing
+values in a different way as compared to the standard X11 format.
+
+X11:
+HTimings:  hdisp hsyncstart hsyncend htotal
+VTimings:  vdisp vsyncstart vsyncend vtotal
+
+EDID:
+#define XPIX hdisp
+#define XBLANK htotal-hdisp
+#define XOFFSET hsyncstart-hdisp
+#define XPULSE hsyncend-hsyncstart
+
+#define YPIX vdisp
+#define YBLANK vtotal-vdisp
+#define YOFFSET (63+(vsyncstart-vdisp))
+#define YPULSE (63+(vsyncend-vsyncstart))
+
+The CRC value in the last line
   #define CRC 0x55
-is a bit tricky. After a first version of the binary data set is
-created, it must be be checked with the "edid-decode" utility which will
+also is a bit tricky. After a first version of the binary data set is
+created, it must be checked with the "edid-decode" utility which will
 most probably complain about a wrong CRC. Fortunately, the utility also
 displays the correct CRC which must then be inserted into the source
 file. After the make procedure is repeated, the EDID data set is ready

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Fix potential memory leak in edid_load()

[Carsten Emde]

On 08/07/2012 02:23 PM, Alexey Khoroshilov wrote:

Do not leak memory by updating pointer with potentially
NULL realloc return value.

Found by Linux Driver Verification project (linuxtesting.org).

Thanks, Alexey!

Reviewed-by: Carsten Emde 


Signed-off-by: Alexey Khoroshilov 
---
  drivers/gpu/drm/drm_edid_load.c |8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 66d4a28..0303935 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -119,7 +119,7 @@ static int edid_load(struct drm_connector *connector, char 
*name,
  {
const struct firmware *fw;
struct platform_device *pdev;
-   u8 *fwdata = NULL, *edid;
+   u8 *fwdata = NULL, *edid, *new_edid;
int fwsize, expected;
int builtin = 0, err = 0;
int i, valid_extensions = 0;
@@ -195,12 +195,14 @@ static int edid_load(struct drm_connector *connector, 
char *name,
"\"%s\" for connector \"%s\"\n", valid_extensions,
edid[0x7e], name, connector_name);
edid[0x7e] = valid_extensions;
-   edid = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH,
+   new_edid = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH,
GFP_KERNEL);
-   if (edid == NULL) {
+   if (new_edid == NULL) {
err = -ENOMEM;
+   kfree(edid);
goto relfw_out;
}
+   edid = new_edid;
}

connector->display_info.raw_edid = edid;

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/1] drm: Add built-in EDID set of another common screen resolution

[Carsten Emde]

Several users were complaining that 1600x1200 screen resolution was
lacking. Here is it.

-Carsten. 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/1] drm: Add 1600x1200 (UXGA) screen resolution to the built-in EDIDs

[Carsten Emde]

The 1600x1200 (UXGA) screen resolution was lacking in the set of
built-in selectable EDID screen resolutions that can be used to
repair misbehaving monitor firmware.

This patch adds the related data set and expands the documentation.
 
Signed-off-by: Carsten Emde 

---
 Documentation/EDID/1600x1200.S  |   44 
 Documentation/EDID/HOWTO.txt|   12 +-
 drivers/gpu/drm/drm_edid_load.c |   21 ++-
 3 files changed, 70 insertions(+), 7 deletions(-)

Index: linux/Documentation/EDID/1600x1200.S
===
--- /dev/null
+++ linux/Documentation/EDID/1600x1200.S
@@ -0,0 +1,44 @@
+/*
+   1600x1200.S: EDID data set for standard 1600x1200 60 Hz monitor
+
+   Copyright (C) 2013 Carsten Emde 
+
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either version 2
+   of the License, or (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA.
+*/
+
+/* EDID */
+#define VERSION 1
+#define REVISION 3
+
+/* Display */
+#define CLOCK 162000 /* kHz */
+#define XPIX 1600
+#define YPIX 1200
+#define XY_RATIO XY_RATIO_4_3
+#define XBLANK 560
+#define YBLANK 50
+#define XOFFSET 64
+#define XPULSE 192
+#define YOFFSET (63+1)
+#define YPULSE (63+3)
+#define DPI 72
+#define VFREQ 60 /* Hz */
+#define TIMING_NAME "Linux UXGA"
+#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
+#define HSYNC_POL 1
+#define VSYNC_POL 1
+#define CRC 0x9d
+
+#include "edid.S"
Index: linux/Documentation/EDID/HOWTO.txt
===
--- linux.orig/Documentation/EDID/HOWTO.txt
+++ linux/Documentation/EDID/HOWTO.txt
@@ -18,12 +18,12 @@ CONFIG_DRM_LOAD_EDID_FIRMWARE was introd
 individually prepared or corrected EDID data set in the /lib/firmware
 directory from where it is loaded via the firmware interface. The code
 (see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for
-commonly used screen resolutions (1024x768, 1280x1024, 1680x1050,
-1920x1080) as binary blobs, but the kernel source tree does not contain
-code to create these data. In order to elucidate the origin of the
-built-in binary EDID blobs and to facilitate the creation of individual
-data for a specific misbehaving monitor, commented sources and a
-Makefile environment are given here.
+commonly used screen resolutions (1024x768, 1280x1024, 1600x1200,
+1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
+not contain code to create these data. In order to elucidate the origin
+of the built-in binary EDID blobs and to facilitate the creation of
+individual data for a specific misbehaving monitor, commented sources
+and a Makefile environment are given here.
 
 To create binary EDID and C source code files from the existing data
 material, simply type "make".
Index: linux/drivers/gpu/drm/drm_edid_load.c
===
--- linux.orig/drivers/gpu/drm/drm_edid_load.c
+++ linux/drivers/gpu/drm/drm_edid_load.c
@@ -31,10 +31,11 @@ module_param_string(edid_firmware, edid_
 MODULE_PARM_DESC(edid_firmware, "Do not probe monitor, use specified EDID blob 
"
"from built-in data or /lib/firmware instead. ");
 
-#define GENERIC_EDIDS 4
+#define GENERIC_EDIDS 5
 static char *generic_edid_name[GENERIC_EDIDS] = {
"edid/1024x768.bin",
"edid/1280x1024.bin",
+   "edid/1600x1200.bin",
"edid/1680x1050.bin",
"edid/1920x1080.bin",
 };
@@ -79,6 +80,24 @@ static u8 generic_edid[GENERIC_EDIDS][12
{
0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00,
0x31, 0xd8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+   0x05, 0x16, 0x01, 0x03, 0x6d, 0x37, 0x29, 0x78,
+   0xea, 0x5e, 0xc0, 0xa4, 0x59, 0x4a, 0x98, 0x25,
+   0x20, 0x50, 0x54, 0x00, 0x00, 0x00, 0xa9, 0x40,
+   0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
+   0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x48, 0x3f,
+   0x40, 0x30, 0x62, 0xb0, 0x32, 0x40, 0x40, 0xc0,
+   0x13, 0x00, 0x2b, 0xa0, 0x21, 0x00, 0x00, 0x1e,
+   0x00, 0x00, 0x00, 0xff, 0x00, 0x4c, 0x69, 0x6e,
+   0x75, 0x78, 0x20, 0x23, 0x30, 0x0a, 0x20, 0x20,
+   0x20, 0x20, 0x00, 0x00, 0x00, 0xfd, 0x00, 0x3b,
+   0x3d, 0x4a, 0x4c, 0x11, 0x00, 0x0a, 0x20, 0x20,
+   0x20, 0x20, 0x20, 0x20, 0x00, 0x00

[PATCH 0/1] drm-set-default-noedid-res.patch

[Carsten Emde]

Hi,

Some monitors and, more often, kvm switches do not provide working EDID
data. KMS based X configurations in recent server versions no longer
allow to override the screen resolution which makes it impossible to
correctly adapt the screen resolution to the monitor in use.

This patch allows to define the fallback screen resolution to something
else than the default 1024x768.

Carsten.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/1] drm-set-default-noedid-res.patch

[Carsten Emde]

A default resolution of 1024x768 is used, if there are no
EDID data. However, this may not always be appropriate.

This patch introduces the kernel parameter drm.noedidres
that has the format "x". If specified, it will
override the default.

Example: drm.noedidres=1280x1024

Signed-off-by: Carsten Emde 

---
 drivers/gpu/drm/drm_crtc_helper.c |   14 +-
 drivers/gpu/drm/drm_stub.c|5 +
 include/drm/drmP.h|1 +
 3 files changed, 19 insertions(+), 1 deletion(-)

Index: head/drivers/gpu/drm/drm_crtc_helper.c
===
--- head.orig/drivers/gpu/drm/drm_crtc_helper.c
+++ head/drivers/gpu/drm/drm_crtc_helper.c
@@ -110,9 +110,21 @@ int drm_helper_probe_single_connector_mo
 
count = (*connector_funcs->get_modes)(connector);
if (!count) {
-   count = drm_add_modes_noedid(connector, 1024, 768);
+   unsigned long x = 1024, y = 768;
+
+   if (drm_noedidres != NULL) {
+   unsigned long nx, ny;
+
+   if (sscanf(drm_noedidres, "%lux%lu", &nx, &ny) == 2) {
+   x = nx;
+   y = ny;
+   }
+   }
+   count = drm_add_modes_noedid(connector, x, y);
if (!count)
return 0;
+   DRM_DEBUG_KMS("no EDID, added mode %lux%lu to connector %s\n",
+   x, y, drm_get_connector_name(connector));
}
 
drm_mode_connector_list_update(connector);
Index: head/drivers/gpu/drm/drm_stub.c
===
--- head.orig/drivers/gpu/drm/drm_stub.c
+++ head/drivers/gpu/drm/drm_stub.c
@@ -40,12 +40,17 @@
 unsigned int drm_debug = 0;/* 1 to enable debug output */
 EXPORT_SYMBOL(drm_debug);
 
+char *drm_noedidres;   /* screen "x", if no EDID data */
+EXPORT_SYMBOL(drm_noedidres);
+
 MODULE_AUTHOR(CORE_AUTHOR);
 MODULE_DESCRIPTION(CORE_DESC);
 MODULE_LICENSE("GPL and additional rights");
 MODULE_PARM_DESC(debug, "Enable debug output");
+MODULE_PARM_DESC(noedidres, "Screen \"x\", if no EDID data");
 
 module_param_named(debug, drm_debug, int, 0600);
+module_param_named(noedidres, drm_noedidres, charp, 0600);
 
 struct idr drm_minors_idr;
 
Index: head/include/drm/drmP.h
===
--- head.orig/include/drm/drmP.h
+++ head/include/drm/drmP.h
@@ -1356,6 +1356,7 @@ extern int drm_get_dev(struct pci_dev *p
 extern void drm_put_dev(struct drm_device *dev);
 extern int drm_put_minor(struct drm_minor **minor);
 extern unsigned int drm_debug;
+extern char *drm_noedidres;
 
 extern struct class *drm_class;
 extern struct proc_dir_entry *drm_proc_root;

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/1] drm-set-default-noedid-res.patch

[Carsten Emde]

Dave,


Some monitors and, more often, kvm switches do not provide working
EDID data. KMS based X configurations in recent server versions no
longer allow to override the screen resolution which makes it
impossible to correctly adapt the screen resolution to the monitor
in use. This patch allows to define the fallback screen resolution
to something else than the default 1024x768.

Does video=800x600 not work for you?

No, this only sets the tty resolution; the resolution of the X server
appears to be limited to the maximum as specified at line 123 in
drivers/gpu/drm/drm_crtc_helper.c:
  drm_add_modes_noedid(connector, x, y);

kernel parameter   TTY resolution  Max. X resolution
 -   640x480 1024x768
vga=0x31b   1280x10241024x768
video=1280x1024 1280x10241024x768
video=1280x1024 vga=0x31b   1280x10241024x768
drm.noedidres   1280x10241280x1024
drm.noedidres vga=0x31b 1280x10241280x1024

X.Org X Server 1.7.6
Build ID: xorg-x11-server 1.7.6-4.fc12

Carsten.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC] Re: [PATCH 0/1] drm-set-default-noedid-res.patch

[Carsten Emde]

Dave,

>> Some monitors and, more often, kvm switches do not provide working
>> EDID data. KMS based X configurations in recent server versions no
>> longer allow to override the screen resolution which makes it
>> impossible to correctly adapt the screen resolution to the monitor
>> in use. This patch allows to define the fallback screen resolution
>> to something else than the default 1024x768.
> Does video=800x600 not work for you?
I did a lot more tests; apparently, things are even more difficult than
expected.

These are my observations (all with Radeon X1950 and radeon driver):

- On the monitor side:
In addition to the known quirks, the EDID data may not be accessible or
erroneous. The original patch only solved the situation of unavailable
EDID data. A frequent reason of erroneous or unavailable EDID data is
the use of suboptimally designed KVM switches that are unable to probe
the connected monitor and send no or fantasy EDID data.

- On the Xorg side:
Older radeon drivers recognize the options "IgnoreEDID" and "NoDDC".
Using this trick, Xorg can be forced to disregard any EDID data and use
the resolution as specified in xorg.conf.

Less old radeon drivers still recognize the option "IgnoreEDID", but
this does not work any longer, since the option "NoDDC" has been
abandoned. Such drivers rely on correct EDID data.

Current radeon drivers should have the option "CustomEDID" to override
the probed EDID data (at least this is what the manual says), but I
couldn't get it working. The log file insists on saying that the option
"CustomEDID" is not used. These drivers also rely on correct EDID data.


My conclusion is, that the right place to solve the situation is in the
kernel. The attached patch makes the sysfs edid entry writable. If the
name of an existing binary EDID data file in /lib/firmware is supplied
such as

  cd /sys/devices/pci:00/:00:07.0/:05:00.0/drm/card0
  echo dvi_0.bin >card0-DVI-I-1/edid

the related connector will be set to these EDID data. Any probing is
then disabled. To restore the previous behavior and to re-enable monitor
probing, an empty string or a single line delimiter must be sent:

  echo >card0-DVI-I-1/edid

I have tested the patch successfully in a number of different
configurations. When userspace setup tools such as
gnome-display-properties are used, the name and resolution data of the
provided (fake) EDID data are correctly decoded.

When compared to the various X hacks I tried, I find this solution
better, since it solves the problem at a place where it belongs. This is
in line with the observation that EDID related functionality appears to
fade out of X drivers.

Does this make sense?

Carsten.

Use the firmware interface to load binary EDID data from
a file and use them to assign monitor data to a video
connector.

Signed-off-by: Carsten Emde 

---
 drivers/gpu/drm/drm_crtc_helper.c |7 
 drivers/gpu/drm/drm_edid.c|5 +++
 drivers/gpu/drm/drm_sysfs.c   |   63 +-
 include/drm/drm_crtc.h|1 
 4 files changed, 75 insertions(+), 1 deletion(-)

Index: linux-2.6.34/drivers/gpu/drm/drm_crtc_helper.c
===
--- linux-2.6.34.orig/drivers/gpu/drm/drm_crtc_helper.c
+++ linux-2.6.34/drivers/gpu/drm/drm_crtc_helper.c
@@ -87,6 +87,13 @@ int drm_helper_probe_single_connector_mo
 	int mode_flags = 0;
 
 	DRM_DEBUG_KMS("%s\n", drm_get_connector_name(connector));
+
+	if (connector->edid_pinned) {
+		list_for_each_entry(mode, &connector->modes, head)
+			count++;
+		return count;
+	}
+
 	/* set all modes to the unverified state */
 	list_for_each_entry_safe(mode, t, &connector->modes, head)
 		mode->status = MODE_UNVERIFIED;
Index: linux-2.6.34/drivers/gpu/drm/drm_edid.c
===
--- linux-2.6.34.orig/drivers/gpu/drm/drm_edid.c
+++ linux-2.6.34/drivers/gpu/drm/drm_edid.c
@@ -1214,6 +1214,11 @@ struct edid *drm_get_edid(struct drm_con
 	int ret;
 	struct edid *edid;
 
+	if (connector->edid_pinned) {
+		edid = (struct edid *) connector->display_info.raw_edid;
+		goto end;
+	}
+
 	edid = kmalloc(EDID_LENGTH * (DRM_MAX_EDID_EXT_NUM + 1),
 		   GFP_KERNEL);
 	if (edid == NULL) {
Index: linux-2.6.34/drivers/gpu/drm/drm_sysfs.c
===
--- linux-2.6.34.orig/drivers/gpu/drm/drm_sysfs.c
+++ linux-2.6.34/drivers/gpu/drm/drm_sysfs.c
@@ -16,9 +16,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_sysfs.h"
 #include "drm_core.h"
+#include "drm_edid.h"
 #include "drmP.h"
 
 #define to_drm_minor(d) container_of(d, struct drm_minor, kdev)
@@ -219,6 +221,64 @@ static ssize_t edid_show(struct kobject 
 	return count;
 }
 
+s

[PATCH 1/3] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

Michael,

> On Sun, 11 Mar 2012 22:23:22 +0100, Carsten Emde wrote:
>> On 03/11/2012 02:44 PM, Alan Cox wrote:
>>>> This patch allows to load an EDID data set via the firmware interface.
>>>> It contains data sets of frequently used screen resolutions (1024x768,
>>>> 1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
>>>> specified as a module parameter of the drm_kms_helper module, e.g.
>>>> options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
>>>> command line parameter.
>>> What if the DRM layer and driver are compiled in. They'll come up as
>>> console before the file system so the firmware request will hang ?
>> Admittedly I did not try to compile the DRM layer and driver into the
>> kernel. However, I created an error condition by specifying a
>> non-existing EDID file. In this case, the function returns with error,
>> the mode count remains 0, and the system continues to run as if the
>> edid_firmware= parameter had not been specified.
> Unfortunately, as of at least last month, my system hangs when I try to
> use your feature (just as described by Alan Cox); the log shows that
> during the boot process, there is a one-minute hang:
>
>[0.175207] [drm] radeon: power management initialized
>[   60.896507] [drm:edid_load] *ERROR* Requesting EDID firmware 
> "edid/1920x1200.bin" failed (err=-2)
>
> Is there any way to make your feature smarter about its timing with
> relation to file system accessibility?
Sure.

Please copy your EDID data file to the directory "firmware/edid" of the 
kernel source tree, configure

CONFIG_EXTRA_FIRMWARE="edid/1920x1200.bin"
CONFIG_EXTRA_FIRMWARE_DIR="firmware"

and rebuild/reboot your kernel.

Does it work then?

-Carsten.

[PATCH] drm/edid: Fix potential memory leak in edid_load()

[Carsten Emde]

On 08/07/2012 02:23 PM, Alexey Khoroshilov wrote:
> Do not leak memory by updating pointer with potentially
> NULL realloc return value.
>
> Found by Linux Driver Verification project (linuxtesting.org).
Thanks, Alexey!

Reviewed-by: Carsten Emde 

> Signed-off-by: Alexey Khoroshilov 
> ---
>   drivers/gpu/drm/drm_edid_load.c |8 +---
>   1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index 66d4a28..0303935 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -119,7 +119,7 @@ static int edid_load(struct drm_connector *connector, 
> char *name,
>   {
>   const struct firmware *fw;
>   struct platform_device *pdev;
> - u8 *fwdata = NULL, *edid;
> + u8 *fwdata = NULL, *edid, *new_edid;
>   int fwsize, expected;
>   int builtin = 0, err = 0;
>   int i, valid_extensions = 0;
> @@ -195,12 +195,14 @@ static int edid_load(struct drm_connector *connector, 
> char *name,
>   "\"%s\" for connector \"%s\"\n", valid_extensions,
>   edid[0x7e], name, connector_name);
>   edid[0x7e] = valid_extensions;
> - edid = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH,
> + new_edid = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH,
>   GFP_KERNEL);
> - if (edid == NULL) {
> + if (new_edid == NULL) {
>   err = -ENOMEM;
> + kfree(edid);
>   goto relfw_out;
>   }
> + edid = new_edid;
>   }
>
>   connector->display_info.raw_edid = edid;

[PATCH 0/1] drm-set-default-noedid-res.patch

[Carsten Emde]

Hi,

Some monitors and, more often, kvm switches do not provide working EDID
data. KMS based X configurations in recent server versions no longer
allow to override the screen resolution which makes it impossible to
correctly adapt the screen resolution to the monitor in use.

This patch allows to define the fallback screen resolution to something
else than the default 1024x768.

Carsten.

[PATCH 1/1] drm-set-default-noedid-res.patch

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drm-set-default-noedid-res.patch
URL: 

[PATCH 0/1] drm-set-default-noedid-res.patch

[Carsten Emde]

Dave,

>> Some monitors and, more often, kvm switches do not provide working
>> EDID data. KMS based X configurations in recent server versions no
>> longer allow to override the screen resolution which makes it
>> impossible to correctly adapt the screen resolution to the monitor
>> in use. This patch allows to define the fallback screen resolution
>> to something else than the default 1024x768.
> Does video=800x600 not work for you?
No, this only sets the tty resolution; the resolution of the X server
appears to be limited to the maximum as specified at line 123 in
drivers/gpu/drm/drm_crtc_helper.c:
   drm_add_modes_noedid(connector, x, y);

kernel parameter   TTY resolution  Max. X resolution
  -   640x480 1024x768
vga=0x31b   1280x10241024x768
video=1280x1024 1280x10241024x768
video=1280x1024 vga=0x31b   1280x10241024x768
drm.noedidres   1280x10241280x1024
drm.noedidres vga=0x31b 1280x10241280x1024

X.Org X Server 1.7.6
Build ID: xorg-x11-server 1.7.6-4.fc12

Carsten.

[RFC] Re: [PATCH 0/1] drm-set-default-noedid-res.patch

[Carsten Emde]

Dave,

>> Some monitors and, more often, kvm switches do not provide working
>> EDID data. KMS based X configurations in recent server versions no
>> longer allow to override the screen resolution which makes it
>> impossible to correctly adapt the screen resolution to the monitor
>> in use. This patch allows to define the fallback screen resolution
>> to something else than the default 1024x768.
> Does video=800x600 not work for you?
I did a lot more tests; apparently, things are even more difficult than
expected.

These are my observations (all with Radeon X1950 and radeon driver):

- On the monitor side:
In addition to the known quirks, the EDID data may not be accessible or
erroneous. The original patch only solved the situation of unavailable
EDID data. A frequent reason of erroneous or unavailable EDID data is
the use of suboptimally designed KVM switches that are unable to probe
the connected monitor and send no or fantasy EDID data.

- On the Xorg side:
Older radeon drivers recognize the options "IgnoreEDID" and "NoDDC".
Using this trick, Xorg can be forced to disregard any EDID data and use
the resolution as specified in xorg.conf.

Less old radeon drivers still recognize the option "IgnoreEDID", but
this does not work any longer, since the option "NoDDC" has been
abandoned. Such drivers rely on correct EDID data.

Current radeon drivers should have the option "CustomEDID" to override
the probed EDID data (at least this is what the manual says), but I
couldn't get it working. The log file insists on saying that the option
"CustomEDID" is not used. These drivers also rely on correct EDID data.


My conclusion is, that the right place to solve the situation is in the
kernel. The attached patch makes the sysfs edid entry writable. If the
name of an existing binary EDID data file in /lib/firmware is supplied
such as

  cd /sys/devices/pci:00/:00:07.0/:05:00.0/drm/card0
  echo dvi_0.bin >card0-DVI-I-1/edid

the related connector will be set to these EDID data. Any probing is
then disabled. To restore the previous behavior and to re-enable monitor
probing, an empty string or a single line delimiter must be sent:

  echo >card0-DVI-I-1/edid

I have tested the patch successfully in a number of different
configurations. When userspace setup tools such as
gnome-display-properties are used, the name and resolution data of the
provided (fake) EDID data are correctly decoded.

When compared to the various X hacks I tried, I find this solution
better, since it solves the problem at a place where it belongs. This is
in line with the observation that EDID related functionality appears to
fade out of X drivers.

Does this make sense?

Carsten.
-- next part --
A non-text attachment was scrubbed...
Name: drivers-gpu-drm-allow-to-load-edid-firmware.patch
Type: text/x-patch
Size: 4333 bytes
Desc: not available
URL: 

[PATCH 0/1] drm: Add built-in EDID set of another common screen resolution

[Carsten Emde]

Several users were complaining that 1600x1200 screen resolution was
lacking. Here is it.

-Carsten. 

[PATCH 1/1] drm: Add 1600x1200 (UXGA) screen resolution to the built-in EDIDs

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-edid-load-firmware-add-1600x1200.patch
URL: 

[PATCH 0/1] Improve documentation to create an EDID data set

[Carsten Emde]

Among the (predominantly positive) feedback to the EDID firmware loader
(http://lists.freedesktop.org/archives/dri-devel/2012-March/020292.html),
there was a complaint that the documentation could be clearer how to
create a particular EDID data set from timing data in X11 format.

This patch adds a related section to the documentation. 

-Carsten. 

[PATCH 1/1] Load EDID: Explain better how to write your own EDID firmware

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: edid-howto-explain-timing-vars-better.patch
URL: 

[PATCH 0/3] Provide workarounds to use DRM/KMS with broken graphics hardware

[Carsten Emde]

In the good old days when graphics parameters were configured explicitly
in a file called xorg.conf, even broken hardware could be managed.

Today, with the advent of Kernel Mode Setting, a graphics board is
either correctly working because all components follow the standards -
or the computer is unusable, because the screen remains dark after
booting or displays the wrong area. Cases when this happens are:
- The BIOS assumes that an LVDS is always connected, even if it isn't.
- The graphics board does not recognize the monitor.
- The graphics board is unable to detect any EDID data.
- The graphics board incorrectly forwards EDID data to the driver.
- The monitor sends bogus EDID data.
- A KVM sends its own EDID data instead of querying the connected monitor.
- The brightness setting of the panel backlight does not work.
- Any combination of the above.
Adding the kernel parameter "nomodeset" helps in most cases, but causes
restrictions later on.

The three patches of this series add module parameters to the
drm_kms_helper module that
1. allow to load an EDID data set via the firmware interface,
2. provide a module parameter to selectively enable or disable a
graphics port,
3. provide a module parameter to select inverted brightness.

EDID data sets along with source files are provided for commonly used
screen resolutions (1024x768, 1280x1024, 1680x1050, 1920x1080).

Please note that these patches neither fix a kernel bug nor provide any
extra functionality. They simply work around broken hardware that
otherwise would be either unusable or usable in a very restricted way.
The patches do not modify the current functionality of the related
components in any way, unless the kernel is configured accordingly
and/or the newly provided module parameters are set.

-Carsten. 

[PATCH 3/3] drivers-gpu-drm-i915-invert-backlight-brightness

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-i915-invert-backlight-brightness.patch
URL: 

[PATCH 2/3] drivers-gpu-drm-add-disable-enable-connector.patch

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-add-disable-enable-connector.patch
URL: 

[PATCH 1/3] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-allow-to-load-edid-firmware.patch
URL: 

[PATCH 2/3] drivers-gpu-drm-add-disable-enable-connector.patch

[Carsten Emde]

On 03/11/2012 08:20 AM, Dave Airlie wrote:
> On Sat, Mar 10, 2012 at 8:20 PM, Carsten Emde  wrote:
>> Some recent integrated graphics chipset, notably Intel's "Pineview", also
>> provide on-chip LVDS support. As an extra service, the LVDS interface 
>> supplies
>> EDID data - irrespective of whether an LVDS panel is connected or not. The
>> drm_mode_getresources() function, therefore, causes Xorg to always include
>> the LVDS panel into the display and initialize a separate screen for it. e.g.
>> (II) intel(0): Output LVDS1 connected
>> (II) intel(0): Output VGA1 connected
>> (II) intel(0): Using spanning desktop for initial modes
>> (II) intel(0): Output LVDS1 using initial mode 1024x768 +0+0
>> (II) intel(0): Output VGA1 using initial mode 1280x1024 +1024+0
>> which is not what you want, if the only connected screen is a VGA monitor.
>> One would assume that the BIOS settings of such systems would allow to
>> separately enable or disable LVDS support; unfortunately, systems have been
>> found in the wild that do not provide this feature.
>
> So video=LVDS-1:d doesn't work for you?
Oops, yes, you are totally right. By some reason, I overlooked this 
option. I tried two systems that need forced disabling and enabling with
   video=LVDS-1:d video=VGA-1:e
which worked perfectly well.

So please skip this patch, sorry for the noise.

Thanks,
-Carsten.

[PATCH 1/3] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

On 03/11/2012 02:44 PM, Alan Cox wrote:
>> This patch allows to load an EDID data set via the firmware interface.
>> It contains data sets of frequently used screen resolutions (1024x768,
>> 1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
>> specified as a module parameter of the drm_kms_helper module, e.g.
>> options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
>> command line parameter.
>
> What if the DRM layer and driver are compiled in. They'll come up as
> console before the file system so the firmware request will hang ?
Admittedly I did not try to compile the DRM layer and driver into the 
kernel. However, I created an error condition by specifying a 
non-existing EDID file. In this case, the function returns with error, 
the mode count remains 0, and the system continues to run as if the 
edid_firmware= parameter had not been specified.

Now that you were asking, I created a static kernel and did some more 
tests, but I couldn't find any problem. Everything worked as expected. I 
believe that the early console still runs in BIOS VGA mode, i.e. either 
using the BIOS default mode or the one that was specified using the vga= 
parameter, if any. DRM apparently comes into play at a later stage only, 
but I will do some more testing.

> Given the EDID is tiny and is data not code wouldn't it be simpler (and
> smaller) if this option compiled in a few generic EDIDs to use ?
Yes, this certainly would be possible. However, we would loose the 
flexibility to specify an individual EDID data set without recompiling 
the kernel. As an alternative, we could compile the four standard EDIDs 
into the DRM helper instead of providing them as a file, but still leave 
the option to load an individual EDID via the firmware interface. This 
would make the patch much smaller and avoid spamming the firmware 
directory. How about that?

Thanks,
-Carsten.

[PATCH 1/3] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

Alan,

>> This patch allows to load an EDID data set via the firmware interface.
>> It contains data sets of frequently used screen resolutions (1024x768,
>> 1280x1024, 1680x1050 and 1920x1080). The requested EDID data are
>> specified as a module parameter of the drm_kms_helper module, e.g.
>> options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel
>> command line parameter.
> [..]
> Given the EDID is tiny and is data not code wouldn't it be simpler (and
> smaller) if this option compiled in a few generic EDIDs to use ?
I liked the idea so much that I gave it a try. The patch looks much 
better now, but has the same functionality as before. As the only 
disadvantage, the patch no longer contains the template to produce a 
particular EDID. But this code may be made available elsewhere - no need 
to have it in the kernel.

Hope you like it.

Thanks,
-Carsten.
-- next part --
A non-text attachment was scrubbed...
Name: drivers-gpu-drm-allow-to-load-edid-firmware.patch
Type: text/x-patch
Size: 15365 bytes
Desc: not available
URL: 

[V2 PATCH 0/2] Provide workarounds to use DRM/KMS with broken graphics hardware

[Carsten Emde]

This is V2 of a patchset to use DRM/KMS with broken graphics hardware.

As a major change from V1, generic EDID data are now built-in into the
drm_kms_helper module as proposed by Alan. To help people building
their own EDID data and to understand how the binary EDID blobs in
drivers/gpu/drm/drm_edid_load.c have been created, the entire material
went into the Documentation tree as suggested by Valdis. Finally, David
showed a much better way to explicitly disable and enable a particular
connector, so patch 02/03 could go.

The two remaining patches
- introduce a mechanism to define or load EDID data instead of letting the
controller probe for it,
- add a parameter to the i915 module to invert the sense of the backlight
brightness variable for broken controllers that require this.

-Carsten.

[V2 PATCH 2/2] drivers-gpu-drm-i915-invert-backlight-brightness

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-i915-invert-backlight-brightness.patch
URL: 

[V2 PATCH 1/2] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-allow-to-load-edid-firmware.patch
URL: 

[V3 PATCH 2/2] drivers-gpu-drm-i915-quirk-backlight-inverted.patch

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-i915-quirk-backlight-inverted.patch
URL: 

[V3 PATCH 1/2] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-allow-to-load-edid-firmware.patch
URL: 

[V3 PATCH 1/2] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

Bastien,

>> 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
>
> Windows allow vendor to override eddid based on 3 bytes manufacturer
> and product code.
This may solve the situation when a particular monitor lies about the
required setting or its EDID data set has an invalid CRC. However, this
does not solve the situation when we do not get any useful EDID
information, because something is totally broken. This also applies to
the KVM situation when the KVM sends EDID data that are totally
unrelated to the monitor at the other side of the KVM.

> Seems a reasonnable approach to follow.
I am not yet convinced.

-Carsten.

[V3 PATCH 0/2] Provide workarounds to use DRM/KMS with broken graphics hardware

[Carsten Emde]

Changes from V2 to V3:

1. The help text of the DRM_LOAD_EDID_FIRMWARE Kconfig item and the
related explanation in Documentation/kernel-parameters.txt now contain
a pointer to the documentation as suggested by Paul.
2. Removed the "brightness_inverted" parameter of the i915 module and
replaced it by a quirk that is specific to the affected Acer Aspire 5734Z
notebook as suggested by Keith.

Thanks,
-Carsten.

[V4 PATCH 0/2] Provide workarounds to use DRM/KMS with broken graphics hardware

[Carsten Emde]

Changes from V3 to V4:

Reverted the removal of the "brightness_inverted" parameter of the i915
module as suggested by Chris. Inversion of the sense of the brightness
variable is now enabled, if either the quirked notebook is encountered
or the "brightness_inverted" module parameter switch is set.

Thanks,
-Carsten.

[V4 PATCH 2/2] drivers-gpu-drm-i915-backlight-brightness-inverted.patch

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-i915-backlight-brightness-inverted.patch
URL: 

[V4 PATCH 1/2] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-allow-to-load-edid-firmware.patch
URL: 

[V5 PATCH 0/4] Provide workarounds to use DRM/KMS with broken graphics hardware

[Carsten Emde]

Changes from V4 to V5:

1. Split the previous patch 2/2 into three patches to separately i) add the
module parameter, ii) add the quirk infrastructure, and iii) actually quirk
the related machine.

2. Rename the module parameter variable to i915_panel_invert_brightness.

3. Make the module parameter variable tristate to either ignore the
quirk, consider the quirk, if any, or force inversion.

4. Print an instruction along the description of the module parameter to
encourage people sending machine data, should another machine be found
that needs to be quirked.

5. Introduce the function intel_panel_compute_brightness where the
brightness calculation is handled.

Thanks, Chris, for these very valuable suggestions.

-Carsten.

[V5 PATCH 1/4] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-allow-to-load-edid-firmware.patch
URL: 

[V5 PATCH 4/4] drivers-gpu-drm-i915-panel-invert-brightness-acer-aspire-5734z.patch

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-i915-panel-invert-brightness-acer-aspire-5734z.patch
URL: 

[V5 PATCH 3/4] drivers-gpu-drm-i915-panel-invert-brightness-via-quirk.patch

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-i915-panel-invert-brightness-via-quirk.patch
URL: 

[V5 PATCH 2/4] drivers-gpu-drm-i915-panel-invert-brightness-via-parameter.patch

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-i915-panel-invert-brightness-via-parameter.patch
URL: 

[V5 PATCH 1/4] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

Dear Thomas,

> your proposal will not lead to a satisfying solution for those people
> that suffer from monitors and other HW devices that provide wrong
> EDIDs.
Oops, why not?

> Before fetching the display modes, all drm devices will try to detect
> the monitor. If EDID data is not correct (checksum), an error
> notification including an EDID dump will be stored in the logs.
> Depending on the driver (Intel, Radeon, ...) a wrong EDID during
> detection may prevent the further use of the connector until
> detection of a valid EDID.
Yes - until detection of a valid EDID. Specifying the "edid_firmware="
module parameter leads to the detection of a valid EDID and then
everything works - at least, if the specified EDID data is valid. This
works pretty well in more than 15 systems that I tested - admittedly
only Intel and Radeon but many different adapters, monitors and reasons
for misbehavior. Did you try the patch? If so, which graphics adapter
did you try? It is well possible that I overlooked a detail that is not
relevant in the adapters that I tested. Please let me know so I can fix it.

> Furthermore, all current graphic adapters provide at least three and
>  even more connectors. Many people use two monitors in parallel.
This is a good point. I will provide a new version of the patch that
allows to alternatively prepend the connector name to the name of the
EDID firmware separated by a colon such as
   edid_firmware=[:]

> If I understand your patch correctly, it would load EDID defaults
> for all connectors and all monitors, despite of their EDID being
> correct or wrong.
For all connectors with a monitor connected to it, yes. It is impossible
to always decide whether a particular EDID data set is wrong or not. It
may, for example, have a correct CRC but still lie to the connector
about other things such as sync polarity.

> What about audio parameters for HDMI connectors?
Not yet considered.

> On the other hand, there are still KVM switches and monitors out that
> would work correctly. but provide an incorrect, not usuable EDID. If
> we focus the default EDID loading on the buggy EDIDs over a working
> (!) connector, I could imagine a benefit for all users.
Again, this is not possible. Only a human being sitting in front of a
monitor can decide whether a particular EDID data set works or not.

The upcoming version that allows to specify the connector name for a
given EDID firmware probably will solve this situation. If you specify
the EDID firmware for the connector only to which the broken monitor is
connected, the other connectors will not be affected.

Thanks,
-Carsten.

[V6 PATCH 0/1] Provide workarounds to use DRM/KMS with broken graphics hardware

[Carsten Emde]

Changes from V5 to V6:

1. The use of a particular EDID data set can now be restricted to a
given connector using the syntax
  edid_firmware=[:]
as suggested by Thomas Reim.

2. The patches to introduce a module parameter and a quirk to cope with
an inverted brightness variable of some i915 graphics adapters are no
longer part of this patch series.

Thanks,
Carsten.

[V6 PATCH 1/1] drivers-gpu-drm-allow-to-load-edid-firmware.patch

[Carsten Emde]

An embedded and charset-unspecified text was scrubbed...
Name: drivers-gpu-drm-allow-to-load-edid-firmware.patch
URL: 

[OSADL QA 3.18.9-rt4 #1] Radeon driver hangs

[Carsten Emde]

(About 30 OSADL QA Farm systems are now running 3.18.9-rt4. BTW: To 
check out what kernels are under test you may sort the kernel list 
(https://www.osadl.org/?id=933) by kernel version 
(https://www.osadl.org/?id=1001) and scroll down the page.)

The most striking problem of kernel 3.18.9-rt4 affects all systems that 
are equipped with Radeon graphics (irrespective whether PCIe cards or 
APUs with on-chip graphics). They suffer from a hanging radeon driver. 
The block occurs when accelerated graphics load is created by x11perf or 
gltestperf. Sometimes only the graphics are frozen while ssh login still 
is possible, somtimes the entire box is no longer accessible at all. In 
any case, a reboot is needed to recover from this situation.

Here is a selection of kernel messages:

Rack #0/Slot #3 [AMD/ATI] RV730 XT [Radeon HD 4670]:
[16081.272035] INFO: task kworker/u24:4:268 blocked for more than 120 
seconds.
[16081.285776]   Not tainted 3.18.9-rt4 #26
[16081.294286] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
[16081.309901] kworker/u24:4   D 88081ed8b340 0   268  2 
0x1000
[16081.309938] Workqueue: radeon-crtc radeon_flip_work_func [radeon]
[16081.309960]  880805ccfbe8 0046 88081ed0c700 

[16081.309962]  9000 c920 8808112fb420 
880805cc1a10
[16081.309963]  880805ccfbf8 01008108a0da 880805ccfc98 
880805cc1a10
[16081.309966] Call Trace:
[16081.309972]  [] schedule+0x34/0xa0
[16081.309974]  [] schedule_timeout+0x22c/0x2d0
[16081.309984]  [] ? radeon_fence_process+0x16/0x40 
[radeon]
[16081.309993]  [] ? 
radeon_fence_any_seq_signaled+0x44/0x90 [radeon]
[16081.310001]  [] 
radeon_fence_wait_seq_timeout.constprop.8+0x2e7/0x340 [radeon]
[16081.310004]  [] ? __wake_up_sync+0x20/0x20
[16081.310013]  [] radeon_fence_wait+0x86/0xc0 [radeon]
[16081.310023]  [] radeon_flip_work_func+0x15c/0x190 
[radeon]
[16081.310025]  [] process_one_work+0x154/0x450
[16081.310026]  [] worker_thread+0x6b/0x4d0
[16081.310028]  [] ? rescuer_thread+0x290/0x290
[16081.310029]  [] kthread+0xcd/0xf0
[16081.310031]  [] ? kthread_worker_fn+0x1d0/0x1d0
[16081.310034]  [] ret_from_fork+0x7c/0xb0
[16081.310035]  [] ? kthread_worker_fn+0x1d0/0x1d0


Rack #0/Slot #7 [AMD/ATI] Cayman XT [Radeon HD 6970]:
INFO: task Xorg:10038 blocked for more than 120 seconds.
  Not tainted 3.18.9-rt4 #25
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
XorgD 816b7f88 0 10038  10032 0x1044
8800c5ad78e8 0002 88041e80c460 c5c8
88041e80c5c8 0002 c5a8 c5c8
880417728000 88041401 000c 88041401
Call Trace:
[] schedule+0x34/0xa0
[] schedule_timeout+0x204/0x270
[] ? radeon_fence_process+0x16/0x40 [radeon]
[] ? radeon_fence_any_seq_signaled+0x44/0x90 [radeon]
[] 
radeon_fence_wait_seq_timeout.constprop.7+0x227/0x330 [radeon]
[] ? prepare_to_wait_event+0x110/0x110
[] radeon_fence_wait_any+0x57/0x70 [radeon]
[] radeon_sa_bo_new+0x2cf/0x4e0 [radeon]
[] ? debug_smp_processor_id+0x17/0x20
[] radeon_ib_get+0x37/0xf0 [radeon]
[] radeon_cs_ioctl+0x22d/0x820 [radeon]
[] drm_ioctl+0x1a4/0x630 [drm]
[] ? debug_smp_processor_id+0x17/0x20
[] ? unpin_current_cpu+0x1a/0x70
[] ? migrate_enable+0xb0/0x1b0
[] radeon_drm_ioctl+0x4b/0x80 [radeon]
[] do_vfs_ioctl+0x2e0/0x4d0
[] ? __fget+0x72/0xa0
[] SyS_ioctl+0x81/0xa0
[] tracesys_phase2+0xd4/0xd9


Rack #4/Slot #1 Chipset: "KAVERI" (ChipID = 0x130c)
[  600.266245] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
[  600.281856] XorgD 0002 0  3821   3812 
0x00400080
[  600.281865]  880223ddf908 0082 c1c0 
c328
[  600.281867]  88023720c328 0002 c308 
c328
[  600.281869]  81c1b480 880036cfcb60 000c 
880036cfcb60
[  600.281873] Call Trace:
[  600.281882]  [] schedule+0x34/0xa0
[  600.281885]  [] schedule_timeout+0x204/0x270
[  600.281929]  [] ? radeon_fence_process+0x16/0x40 
[radeon]
[  600.281949]  [] ? 
radeon_fence_any_seq_signaled+0x44/0x90 [radeon]
[  600.281968]  [] 
radeon_fence_wait_seq_timeout.constprop.7+0x227/0x330 [radeon]
[  600.281972]  [] ? prepare_to_wait_event+0x110/0x110
[  600.281992]  [] radeon_fence_wait_any+0x57/0x70 
[radeon]
[  600.282023]  [] radeon_sa_bo_new+0x2cf/0x4e0 [radeon]
[  600.282027]  [] ? dequeue_task_fair+0x43e/0x650
[  600.282055]  [] radeon_ib_get+0x37/0xf0 [radeon]
[  600.282078]  [] radeon_cs_ioctl+0x22d/0x820 [radeon]
[  600.282098]  [] drm_ioctl+0x1a4/0x630 [drm]
[  600.282104]  [] ? do_futex+0x109/0xb20
[  600.282106]  [] ? put_prev_entity+0x96/0x3f0
[  600.282122]  [] radeon_drm_ioctl+0xe/0x10 [radeon]
[  600.282125]  [] do_vfs_ioctl+0x2e0/0x4d0
[  600.282128]  [] ? __fget+0x72/0xa0
[  600.282131]  [] SyS_ioctl+0x81/0xa0
[  600.282134]  [] ? __audit_sys

[OSADL QA 3.18.9-rt4 #1] Radeon driver hangs

[Carsten Emde]

Hi Michel,

>> [..]
>> The most striking problem of kernel 3.18.9-rt4 affects all systems that
>> are equipped with Radeon graphics (irrespective whether PCIe cards or
>> APUs with on-chip graphics). They suffer from a hanging radeon driver.
>> The block occurs when accelerated graphics load is created by x11perf or
>> gltestperf. Sometimes only the graphics are frozen while ssh login still
>> is possible, somtimes the entire box is no longer accessible at all. In
>> any case, a reboot is needed to recover from this situation.
>>
>> Here is a selection of kernel messages:
> [...]
> The commits from
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=f957063fee6392bb9365370db6db74dc0b2dce0a
> to
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=cffefd9bb31cd35ab745d3b49005d10616d25bdc
> and
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=b6610101718d4ab90d793c482625e98eb1262cad
> might help for this.

Thanks a lot. I have applied these patches to a number of systems:
# quilt applied | tail -7
patches/drm-radeon-do-a-posting-read-in-r100_set_irq.patch
patches/drm-radeon-do-a-posting-read-in-rs600_set_irq.patch
patches/drm-radeon-do-a-posting-read-in-r600_set_irq.patch
patches/drm-radeon-do-a-posting-read-in-evergreen_set_irq.patch
patches/drm-radeon-do-a-posting-read-in-si_set_irq.patch
patches/drm-radeon-do-a-posting-read-in-cik_set_irq.patch
patches/drm-radeon-fix-wait-to-actually-occur-after-the-signaling-callback.patch

  The graphic boards still crash and freeze the screen, but in contrast
to the earlier situation the systems remain accessible, and the X
Window server can be restarted after the offensive programs are
removed. The crashes were reliably triggered by
- gltestperf
   or
- x11perf -repeat 3 -subs 25 -time 2 -rect10
but the crashes also occur several times per day during normal work
such as browsing the Internet or writing a text document. If you wish
me to provide additional diagnostic information such as running test
programs while the graphic boards are unresponsive, I certainly can do
that.

Below are the related kernel messages.

Thanks,
-Carsten.


Rack #0/Slot #3 [AMD/ATI] RV730 XT [Radeon HD 4670]:

[21001.244036] INFO: task kworker/u24:6:267 blocked for more than 120 
seconds.
[21001.257773]   Not tainted 3.18.9-rt4 #27
[21001.266284] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
[21001.281911] kworker/u24:6   D 88081ed8b340 0   267  2 
0x1000
[21001.281937] Workqueue: radeon-crtc radeon_flip_work_func [radeon]
[21001.281940]  880805d2fbe8 0046 88081ed0c700 

[21001.281941]  9000 c920 8808112fb420 
880035254e30
[21001.281943]  c280 0100c280 0003 
880035254e30
[21001.281945] Call Trace:
[21001.281950]  [] schedule+0x34/0xa0
[21001.281953]  [] schedule_timeout+0x22c/0x2d0
[21001.281962]  [] ? radeon_fence_process+0x16/0x40 
[radeon]
[21001.281971]  [] ? 
radeon_fence_any_seq_signaled+0x44/0x90 [radeon]
[21001.281979]  [] 
radeon_fence_wait_seq_timeout.constprop.8+0x2e7/0x340 [radeon]
[21001.281982]  [] ? __wake_up_sync+0x20/0x20
[21001.281991]  [] radeon_fence_wait+0x86/0xc0 [radeon]
[21001.282000]  [] radeon_flip_work_func+0x15c/0x190 
[radeon]
[21001.282003]  [] process_one_work+0x154/0x450
[21001.282004]  [] worker_thread+0x6b/0x4d0
[21001.282006]  [] ? rescuer_thread+0x290/0x290
[21001.282007]  [] ? rescuer_thread+0x290/0x290
[21001.282009]  [] kthread+0xcd/0xf0
[21001.282010]  [] ? kthread_worker_fn+0x1d0/0x1d0
[21001.282013]  [] ret_from_fork+0x7c/0xb0
[21001.282014]  [] ? kthread_worker_fn+0x1d0/0x1d0


Rack #0/Slot #7 [AMD/ATI] Cayman XT [Radeon HD 6970]

[  481.091132] INFO: task Xorg:3459 blocked for more than 120 seconds.
[  481.103594]   Not tainted 3.18.9-rt4 #28
[  481.112101] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
[  481.127746] XorgD 88041e68ab40 0  3459   3452 
0x1044
[  481.141882]  880413da38e8 0002 88041e60c460 
8800c3ea3380
[  481.141882]  880413da38d8 8108603f c5a8 
c5c8
[  481.141883]  81c19460 8800c3ea3380 000c 
8800c3ea3380
[  481.186228] Call Trace:
[  481.191114]  [] ? queue_delayed_work_on+0xff/0x110
[  481.191118]  [] schedule+0x34/0xa0
[  481.191119]  [] schedule_timeout+0x204/0x270
[  481.191148]  [] ? radeon_fence_process+0x16/0x40 
[radeon]
[  481.191157]  [] ? 
radeon_fence_any_seq_signaled+0x44/0x90 [radeon]
[  481.191165]  [] 
radeon_fence_wait_seq_timeout.constprop.7+0x227/0x330 [radeon]
[  481.191167]  [] ? prepare_to_wait_event+0x110/0x110
[  481.191175]  [] radeon_fence_wait_any+0x57/0x70 
[radeon]
[  481.191191]  [] radeon_sa_bo_new+0x2cf/0x4e0 [radeon]
[  481.191194]  [] ? debug_smp_processor_id+0x17/0x20
[  481.191207]  [] radeon_ib_get+0x37/0xf0 [radeon]
[  481.191218]  [] radeon_cs

[OSADL QA 3.18.9-rt4 #1] Radeon driver hangs

[Carsten Emde]

Hi Michel,

 [..]
 The most striking problem of kernel 3.18.9-rt4 affects all systems that
 are equipped with Radeon graphics (irrespective whether PCIe cards or
 APUs with on-chip graphics). They suffer from a hanging radeon driver.
 The block occurs when accelerated graphics load is created by x11perf or
 gltestperf. Sometimes only the graphics are frozen while ssh login still
 is possible, somtimes the entire box is no longer accessible at all. In
 any case, a reboot is needed to recover from this situation.

 Here is a selection of kernel messages:
>>> [...]
>>> The commits from
>>> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=f957063fee6392bb9365370db6db74dc0b2dce0a
>>>
>>> to
>>> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=cffefd9bb31cd35ab745d3b49005d10616d25bdc
>>>
>>> and
>>> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes&id=b6610101718d4ab90d793c482625e98eb1262cad
>>>
>>> might help for this.
>>
>> Thanks a lot. I have applied these patches to a number of systems:
>> # quilt applied | tail -7
>> patches/drm-radeon-do-a-posting-read-in-r100_set_irq.patch
>> patches/drm-radeon-do-a-posting-read-in-rs600_set_irq.patch
>> patches/drm-radeon-do-a-posting-read-in-r600_set_irq.patch
>> patches/drm-radeon-do-a-posting-read-in-evergreen_set_irq.patch
>> patches/drm-radeon-do-a-posting-read-in-si_set_irq.patch
>> patches/drm-radeon-do-a-posting-read-in-cik_set_irq.patch
>> patches/drm-radeon-fix-wait-to-actually-occur-after-the-signaling-callback.patch
>>
>>
>>   The graphic boards still crash and freeze the screen, but in contrast
>> to the earlier situation the systems remain accessible, and the X
>> Window server can be restarted after the offensive programs are
>> removed. The crashes were reliably triggered by
>> - gltestperf
>>or
>> - x11perf -repeat 3 -subs 25 -time 2 -rect10
This is not entirely correct, since gltestperf does not reliably crash
the graphics controller. However, "x11perf -repeat 3 -subs 25 -time 2
-rect10" always does a reliable job to trigger the crash.

>> but the crashes also occur several times per day during normal work
>> such as browsing the Internet or writing a text document. If you wish
>> me to provide additional diagnostic information such as running test
>> programs while the graphic boards are unresponsive, I certainly can do
>> that.
>
> Does it also happen with a kernel built from a current drm-fixes tree?
> http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes
No. Apparently, you need full preemption to expose the problem.

The following list contains the results whether the command "x11perf
-repeat 3 -subs 25 -time 2 -rect10" freezes the Radeon board under test
(Radeon HD 7970 XFS / R9 280X) or not:
linux-3.12.33-rt47   no
linux-3.14.34-rt32   no
linux-3.14.34-drm-3.16.7-rt32*   no
linux-3.18.7-rt1YES
linux-3.18.9-rt4YES
linux-3.18.9-rt5YES
linux-3.18.9-drm-3.16.7-rt5**no
linux-4.0.0-rc4  no
linux-drm-fixes  no
*DRM subsystem backported from linux-3.16.7 to linux-3.14.34-rt32.
**DRM subsystem ported from linux-3.16.7 to linux-3.18.9-rt5.

More observations:
If full function tracing is enabled (which makes the system about five
times slower), the graphics controller no longer freezes. With partial
function tracing such as "echo *drm* >set_ftrace_filter", the
controller still freezes. The trace then contains vblank interrupt
processing only, ioctls are no longer executed.

This is the location where the driver hangs:
[25104.509258] INFO: task Xorg.bin:16591 blocked for more than 120 seconds.
[25104.516322]   Not tainted 3.18.9-rt5 #2
[25104.520715] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
[25104.528853] Xorg.binD 8171ed90 0 16591  16239 
0x10400080
[25104.536102]  8800ba0bb8d8 0002 8800ba0bbfd8 
0006
[25104.536103]  dc08 880626d0dc08 8800ba0bbfd8 
dc08
[25104.536104]  88061b2cdcd0 880616d3a940 880035c1 
880616d3a940
[25104.559274] Call Trace:
[25104.561844]  [] schedule+0x34/0xa0
[25104.561846]  [] schedule_timeout+0x23c/0x2a0
[25104.561870]  [] ? radeon_fence_process+0x16/0x40 
[radeon]
[25104.561879]  [] ? 
radeon_fence_any_seq_signaled+0x44/0x90 [radeon]
[25104.561887]  [] 
radeon_fence_wait_seq_timeout.constprop.8+0x327/0x380 [radeon]
[25104.561889]  [] ? __wake_up_sync+0x20/0x20
[25104.561898]  [] radeon_fence_wait_any+0x57/0x70 
[radeon]
[25104.561914]  [] radeon_sa_bo_new+0x2af/0x4b0 [radeon]
[25104.561916]  [] ? debug_smp_processor_id+0x17/0x20
[25104.561918]  [] ? __kmalloc+0x8a/0x300
[25104.561932]  [] radeon_ib_get+0x37/0xe0 [radeon]
[25104.561943]  [] radeon_cs_ioctl+0x22e/0x860 [radeon]
[25104.561952]  [] drm_ioctl+0x197/0x670 [drm]
[25104.561954]  [] ? debug_smp_processor_id+0x17/0x20
[25104.561956]