Re: [Intel-gfx] Bug#917280: kernel panic on intel gen4 gfx card
On Tue, 2018-12-25 at 15:45 +, ? ? wrote: > Hi, Greg > > I found on Debian testing with kernel 4.18.20 fail boot, kernel panic > on i915. and reported it to Debian bug 917280 [0], with panic log[1]. > > after revert: > > commit 06e562e7f515292ea7721475950f23554214adde > Author: Chris Wilson > Date: Mon Nov 5 09:43:05 2018 + > > drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5 > > System boots to desktop. > > [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917280 > [1]: > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=917280;filename=dmesg.txt;msg=10 The 4.18 stable branch is no longer maintained. I suspect this is the same as <https://bugs.debian.org/914495> and <https://bugs.freedesktop.org/show_bug.cgi?id=108850>, which is fixed in 4.19 (currently in unstable). Ben. -- Ben Hutchings It is impossible to make anything foolproof because fools are so ingenious. signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-firmware pull request(KBL:DMC)
On Thu, 2017-11-09 at 16:47 -0800, Anusha Srivatsa wrote: > Hi Kyle, > > Please consider pulling i915 updates to linux-firmware.git. > > i915-firmware-KBL-DMC-v1.04: > > The following changes since commit bf04291309d3169c0ad3b8db52564235bbd08e30: > > WHENCE: Add new qed firmware (2017-10-09 18:03:26 +0100) > > are available in the git repository at: > > https://github.com/anushasr/linux-firmware.git > > for you to fetch changes up to 127a9d6eabee487176ad4e377c68199dbb264e08: > > linux-firmware: DMC firmware for kabylake v1.04 (2017-11-09 11:41:47 -0800) > > > Anusha Srivatsa (1): > linux-firmware: DMC firmware for kabylake v1.04 > > WHENCE | 4 > i915/kbl_dmc_ver1_04.bin | Bin 0 -> 8840 bytes > 2 files changed, 4 insertions(+) > create mode 100644 i915/kbl_dmc_ver1_04.bin > > P.S: Kindly Consider these changes and the changes sent in the > Previous pull request. I merged the master branch which was at commit 1156e62c5ec45061955a29e1b9299ffda58479d3, pulling in: Anusha Srivatsa (6): linux-firmware/i915: Add Geminilake DMC version 1.04 linux-firmware/i915: Add Cannonlake DMC version 1.06 linux-firmware: GuC firmware for Skylake v9.33 linux-firmware: GuC firmware for Broxton v9.29 linux-firmware: GuC firmware for kabylake v9.39 linux-firmware: DMC firmware for kabylake v1.04 Sorry for the delay. Ben. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3.16 260/370] drm/i915: Don't leak edid in intel_crt_detect_ddc()
3.16.42-rc1 review patch. If anyone has any objections, please let me know.
--
From: Ander Conselvan de Oliveira <ander.conselvan.de.olive...@intel.com>
commit c34f078675f505c4437919bb1897b1351f16a050 upstream.
In the path where intel_crt_detect_ddc() detects a CRT, if would return
true without freeing the edid.
Fixes: a2bd1f541f19 ("drm/i915: check whether we actually received an edid in
detect_ddc")
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Ander Conselvan de Oliveira
<ander.conselvan.de.olive...@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nik...@intel.com>
Link:
http://patchwork.freedesktop.org/patch/msgid/1484922525-6131-1-git-send-email-ander.conselvan.de.olive...@intel.com
(cherry picked from commit c96b63a6a7ac4bd670ec2e663793a9a31418b790)
Signed-off-by: Jani Nikula <jani.nik...@intel.com>
Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
---
drivers/gpu/drm/i915/intel_crt.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -477,6 +477,7 @@ static bool intel_crt_detect_ddc(struct
struct drm_i915_private *dev_priv = crt->base.base.dev->dev_private;
struct edid *edid;
struct i2c_adapter *i2c;
+ bool ret = false;
BUG_ON(crt->base.type != INTEL_OUTPUT_ANALOG);
@@ -493,17 +494,17 @@ static bool intel_crt_detect_ddc(struct
*/
if (!is_digital) {
DRM_DEBUG_KMS("CRT detected via DDC:0x50 [EDID]\n");
- return true;
+ ret = true;
+ } else {
+ DRM_DEBUG_KMS("CRT not detected via DDC:0x50 [EDID
reports a digital panel]\n");
}
-
- DRM_DEBUG_KMS("CRT not detected via DDC:0x50 [EDID reports a
digital panel]\n");
} else {
DRM_DEBUG_KMS("CRT not detected via DDC:0x50 [no valid EDID
found]\n");
}
kfree(edid);
- return false;
+ return ret;
}
static enum drm_connector_status
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-firmware-i915 pull request (bxt dmc, kbl dmc)
On Tue, 2016-08-02 at 20:48 +, Vivi, Rodrigo wrote: > On Tue, 2016-08-02 at 14:04 +0300, Jani Nikula wrote: [...] > > Why are you deleting old versions? > > Mainly to keep it clean. OSVs pack that entire repo, I don't want i915 > taking unnecessary space from final users. Any filename requested by a driver in a stable release of Linux should not be removed from linux-firmware.git. If it's buggy then it should be replaced it with a fixed version. I can envisage extreme cases where we might make an exception but AFAIK this has not happened yet. The OS vendor knows which kernel versions they want to support and which files can therefore be dropped. I do that for Debian periodically. > > I believe this is another point in favor of bringing the sym links > back. > > But also because we need to remove any firmware that we know it is bad > and that would break the user. If it was blacklisted it was removed > from repo. > > Yet another reason for symbolic link. If we know the firmware is bad it > is bad for previous versions as well, but if we stay with the version > hardcoded we are forcing the user to stay with a firmware that we know > it is bad. Indeed. Please don't put a full version number in the filenames requested by drivers. Where it's not possible to maintain ABI compatibility between driver and firmware indefinitely then include an ABI version in the filename, but not the full version. Ben. -- Ben Hutchings Nothing is ever a complete failure; it can always serve as a bad example. signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3.16.y-ckt 030/168] drm/i915: Handle failure to kick out a conflicting fb driver
On Mon, 2015-01-12 at 18:20 +0100, Daniel Vetter wrote: On Sun, Jan 11, 2015 at 10:49 PM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, 2014-12-15 at 14:24 +, Luis Henriques wrote: 3.16.7-ckt3 -stable review patch. If anyone has any objections, please let me know. -- From: Chris Wilson ch...@chris-wilson.co.uk commit f96de58fc7e7d3d717c7c63975c3b896c906b5e3 upstream. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Jani Nikula jani.nik...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Luis Henriques luis.henriq...@canonical.com Should this also be applied to any older stable branches? i915_kick_out_firmware_fb() was introduced in 3.6 and it has always been possible for the alloc_apertures() call to fail. remove_conflicting_framebuffers() has returned an error code since 3.14 (but could silently fail before then!) so this should be applicable to the 3.14 stable branch too. tbh I don't know why this patch ended up in a stable kernel, at least I didn't find anything where we (drm/i915 maintainers) marked it as such. And there's no bugzilla references added either. Imo the patch doesn't qualify for stable (it's not a real-world bug afaik). [...] It seems to be a dependency of: commit 0485c9dc24ec0939b42ca5104c0373297506b555 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Fri Nov 14 10:09:49 2014 +0100 drm/i915: Kick fbdev before vgacon which was requested for 3.16+. So, neither of these is needed for earlier versions. Sorry for the noise. Ben. -- Ben Hutchings The world is coming to an end. Please log off. signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Backporting drm/i915: force full modeset if the connector is in DPMS OFF mode
On Sun, 2013-06-09 at 11:18 +0200, Daniel Vetter wrote: Hi stable maintainers, Please backport commit e3de42b68478a8c95dd27520e9adead2af9477a5 Author: Imre Deak imre.d...@intel.com Date: Fri May 3 19:44:07 2013 +0200 drm/i915: force full modeset if the connector is in DPMS OFF mode to all supported stable kernels. Additional bugzilla on top of all the others: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65559 You'll need to provide a backport for at least 3.2; this isn't anywhere close to applying. Ben. -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Backport of drm/i915: Fix detection of base of stolen memory
On Tue, 2013-05-21 at 22:27 +0200, Daniel Vetter wrote: Hi Ben, The 3.2.x stable backport patch commit 53e587aa5ca81497d0ea6e340320ec5778d1f311 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Nov 15 11:32:18 2012 + drm/i915: Fix detection of base of stolen memory errornously added a stray return 0; at the wrong spot. It caused a modeset regression at boot for drm/i915. Since we don't ever use stolen mem for anything on 3.2 I think we can savely revert that patch again on 3.2. Upstream kernels (and other stable trees carrying this patch) seem to work fine. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=58511#add_comment Yes, I've already had a report that this is broken. The revert is in my patch queue. Ben. -- Ben Hutchings If at first you don't succeed, you're doing about average. signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915 stable patches
On Mon, 2013-05-06 at 10:36 +0200, Daniel Vetter wrote:
On Mon, May 6, 2013 at 10:33 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Dear stable team,
Please backport
commit 4615d4c9e27eda42c3e965f208a4b4065841498c
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Mon Apr 8 14:28:40 2013 +0100
drm/i915: Use MLC (l3$) for context objects
to all supported stable kernels. It's not just a performance
optimization, but seems to prevent gpu hangs, too.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64073
This one didn't apply to 3.2; I assume it's not needed.
And another one for 3.8 and older:
commit e12a2d53ae45a69aea499b64f75e7222cca0f12f
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: 2012-11-15 11:32:18 +
drm/i915: Fix detection of base of stolen memory
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53541
Looks like the code has moved around a bit. Here's what I ended up with
for 3.2.
Ben.
--
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison
From: Chris Wilson ch...@chris-wilson.co.uk
Date: Thu, 15 Nov 2012 11:32:18 +
Subject: drm/i915: Fix detection of base of stolen memory
commit e12a2d53ae45a69aea499b64f75e7222cca0f12f upstream.
The routine to query the base of stolen memory was using the wrong
registers and the wrong encodings on virtually every platform.
It was not until the G33 refresh, that a PCI config register was
introduced that explicitly said where the stolen memory was. Prior to
865G there was not even a register that said where the end of usable
low memory was and where the stolen memory began (or ended depending
upon chipset). Before then, one has to look at the BIOS memory maps to
find the Top of Memory. Alas that is not exported by arch/x86 and so we
have to resort to disabling stolen memory on gen2 for the time being.
Then SandyBridge enlarged the PCI register to a full 32-bits and change
the encoding of the address, so even though we happened to be querying
the right register, we read the wrong bits and ended up using address 0
for our stolen data, i.e. notably FBC.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/gpu/drm/i915/i915_drv.h|1 +
drivers/gpu/drm/i915/i915_gem_stolen.c | 81
2 files changed, 42 insertions(+), 40 deletions(-)
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -581,6 +581,7 @@ typedef struct drm_i915_private {
unsigned long gtt_start;
unsigned long gtt_mappable_end;
unsigned long gtt_end;
+ unsigned long stolen_base; /* limited to low memory (32-bit) */
struct io_mapping *gtt_mapping;
int gtt_mtrr;
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1007,56 +1007,50 @@ intel_teardown_mchbar(struct drm_device
release_resource(dev_priv-mch_res);
}
-#define PTE_ADDRESS_MASK 0xf000
-#define PTE_ADDRESS_MASK_HIGH 0x00f0 /* i915+ */
-#define PTE_MAPPING_TYPE_UNCACHED (0 1)
-#define PTE_MAPPING_TYPE_DCACHE (1 1) /* i830 only */
-#define PTE_MAPPING_TYPE_CACHED (3 1)
-#define PTE_MAPPING_TYPE_MASK (3 1)
-#define PTE_VALID (1 0)
-
-/**
- * i915_stolen_to_phys - take an offset into stolen memory and turn it into
- * a physical one
- * @dev: drm device
- * @offset: address to translate
- *
- * Some chip functions require allocations from stolen space and need the
- * physical address of the memory in question.
- */
-static unsigned long i915_stolen_to_phys(struct drm_device *dev, u32 offset)
+static unsigned long i915_stolen_to_physical(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct pci_dev *pdev = dev_priv-bridge_dev;
u32 base;
-#if 0
/* On the machines I have tested the Graphics Base of Stolen Memory
- * is unreliable, so compute the base by subtracting the stolen memory
- * from the Top of Low Usable DRAM which is where the BIOS places
- * the graphics stolen memory.
+ * is unreliable, so on those compute the base by subtracting the
+ * stolen memory from the Top of Low Usable DRAM which is where the
+ * BIOS places the graphics stolen memory.
+ *
+ * On gen2, the layout is slightly different with the Graphics Segment
+ * immediately following Top of Memory (or Top of Usable DRAM). Note
+ * it appears that TOUD is only reported by 865g, so we just use the
+ * top of memory as determined by the e820 probe.
+ *
+ * XXX gen2 requires an unavailable symbol and 945gm fails with
+ * its value of TOLUD.
*/
- if (INTEL_INFO(dev)-gen 3 || IS_G33(dev)) {
- /* top 32bits are reserved = 0 */
+ base = 0;
+ if (INTEL_INFO(dev)-gen = 6) {
+ /* Read Base Data of Stolen Memory Register (BDSM) directly.
+ * Note that there is also a MCHBAR miror at 0x1080c0
Re: [Intel-gfx] [3.0.y, 3.2.y, 3.4.y] Please add LVDS patch for the Zotac ZBOX SD ID13
On Sun, 2012-10-21 at 12:41 -0700, Jonathan Nieder wrote: Hi Ben and Greg, Please consider 9756fe38d10b drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13 for application to the 3.0.y, 3.2.y, and 3.4.y trees. It was applied upstream during the 3.6 merge window, so newer kernels don't need it. [...] Added to the queue for 3.2, thanks. Ben. -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction. signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: clear the entire sdvo infoframe buffer
On Sat, 2012-10-20 at 18:33 +0200, Daniel Vetter wrote:
Like in the case of native hdmi, which is fixed already in
commit adf00b26d18e1b3570451296e03bcb20e4798cdd
Author: Paulo Zanoni paulo.r.zan...@intel.com
Date: Tue Sep 25 13:23:34 2012 -0300
drm/i915: make sure we write all the DIP data bytes
we need to clear the entire sdvo buffer to avoid upsetting the
display.
Since infoframe buffer writing is now a bit more elaborate, extract it
into it's own function. This will be useful if we ever get around to
properly update the ELD for sdvo. Also #define proper names for the
two buffer indexes with fixed usage.
v2: Cite the right commit above, spotted by Paulo Zanoni.
v3: I'm too stupid to paste the right commit.
Reported-and-tested-by: Jürg Billeter j...@bitron.ch
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_sdvo.c | 64
++--
drivers/gpu/drm/i915/intel_sdvo_regs.h |2 +
2 files changed, 46 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index d2e8c9f..4bc9c52 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -895,6 +895,47 @@ static void intel_sdvo_dump_hdmi_buf(struct intel_sdvo
*intel_sdvo)
}
#endif
+static bool intel_sdvo_write_infoframe(struct intel_sdvo *intel_sdvo,
+unsigned if_index, uint8_t tx_rate,
+uint8_t *data, unsigned length)
+{
+ uint8_t set_buf_index[2] = { if_index, 0 };
+ uint8_t hbuf_size, tmp[8];
+ int i;
+
+ if (!intel_sdvo_set_value(intel_sdvo,
+ SDVO_CMD_SET_HBUF_INDEX,
+ set_buf_index, 2))
+ return false;
+
+ if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HBUF_INFO,
+ hbuf_size, 1))
+ return false;
+
+ /* Buffer size is 0 base, hooray! */
+ hbuf_size++;
So SDVO_CMD_GET_HBUF_INFO gave us the buffer size in bytes, minus 1?
+ DRM_DEBUG_KMS(writing sdvo hbuf: %i, hbuf_size %i, hbuf_size: %i\n,
+ if_index, length, hbuf_size);
+
+ for (i = 0; i hbuf_size; i += 8) {
+ memset(tmp, 0, 8);
+ memcpy(tmp, data, min_t(unsigned, 8, length));
+
+ if (!intel_sdvo_set_value(intel_sdvo,
+ SDVO_CMD_SET_HBUF_DATA,
+ tmp, 8))
+ return false;
+
+ data += 8;
+ length -= 8;
+ }
[...]
Based on the commit description, I would assume that hbuf_size may be
greater than length initialy, and you're trying to zero-pad here. But
if hbuf_size = length + 8 initially then length can wrap around and
this will continue to read beyond the end of the data array.
I think you could leave data and length unchanged in the loop and then
set up each data chunk like this:
memset(tmp, 0, 8);
if (i length)
memcpy(tmp, data + i, min_t(unsigned, 8, length - i);
Ben.
--
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
- Carolyn Scheppner
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
On Mon, 2012-10-01 at 03:24 -0700, Jonathan Nieder wrote: Hi Ben, Please consider cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29 for application to the 3.2.y tree. It adds a PCI id to the i915 driver, making kms work. It was applied during the 3.4-rc2 cycle, so newer stable kernels don't need it. Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok (thanks!). Note that pre-2.4.34 versions of libdrm don't cope well with that card, with or without this patch: [...] - with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10, X freezes at startup. No regressions means you probably shouldn't take this patch without a safety to work around the old X userspace, [...] Then this workaround is also required in mainline. And once that's done, I can take both patches. Ben. -- Ben Hutchings You can't have everything. Where would you put it? signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
On Sun, 2012-10-07 at 15:11 +0100, Chris Wilson wrote: On Sun, 07 Oct 2012 15:01:17 +0100, Ben Hutchings b...@decadent.org.uk wrote: On Mon, 2012-10-01 at 03:24 -0700, Jonathan Nieder wrote: Hi Ben, Please consider cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29 for application to the 3.2.y tree. It adds a PCI id to the i915 driver, making kms work. It was applied during the 3.4-rc2 cycle, so newer stable kernels don't need it. Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok (thanks!). Note that pre-2.4.34 versions of libdrm don't cope well with that card, with or without this patch: [...] - with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10, X freezes at startup. No regressions means you probably shouldn't take this patch without a safety to work around the old X userspace, [...] Then this workaround is also required in mainline. And once that's done, I can take both patches. The bugs Jonathan mentions are both in userspace packages; not recognising the existence of Bromlow, and then misprogramming it. Yes, I understand that. There are no other kernel patches required specifically for this chipset, afaik. If upgrading the kernel currently triggers a (more) serious bug in typical userland then the kernel should work around that. If I've misunderstood, and the userland behaviour is roughly equally broken with or without this change, then I'll be happy to take it. Ben. -- Ben Hutchings You can't have everything. Where would you put it? signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
