Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
On Tue, 29 Mar 2011 07:49:12 +0100, Chris Wilson wrote: > Yes, Oliver pointed out that we need to pass much more panel > configuration data in order to configure a bare LVDS. Given the bizarre > situation of the LVDS-attached-HDMI PNV boxes (how I love our market > differentiate strategy!), I think we have to accept the user-override. Seems like PNV needs a simpler override (don't use LVDS scaler at all, just set native modes directly). Any chance we could auto-detect this via the LVDS DDC link? -- keith.pack...@intel.com pgpYWDeLlMFCS.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [WIP] i965: Use up to 80 WM threads on GT2.
On Mon, 28 Mar 2011 21:43:28 -0700, Eric Anholt wrote: > On Mon, 28 Mar 2011 15:22:35 -0700, Ian Romanick wrote: > > So, we're currently using too many threads in some cases? Could this be > > related to bug #35730? In that case the failure seems to be limited to > > SugarBay. I believe that's GT1, but I can never get the code names for > > these chips straight. > > Nope, note how instead of using that original wm_max_threads value, 40 > is hardcoded in the place that should have been using it. But for DevSmallGT (which *is* GT1 right?) max VS threads is only 24. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
On Tue, 29 Mar 2011 08:18:49 +0200, Oliver Seitz wrote: > > > Hi Chris, have you updated this patch? > > I think this patch may be obsolete, as these patches > > http://lists.freedesktop.org/archives/intel-gfx/2011-March/009583.html > > do the same and much more. It is not clear yet how to prevent users from > accidentally using these functions which will make the display > unreadable when used carelessly. Yes, Oliver pointed out that we need to pass much more panel configuration data in order to configure a bare LVDS. Given the bizarre situation of the LVDS-attached-HDMI PNV boxes (how I love our market differentiate strategy!), I think we have to accept the user-override. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [WIP] i965: Use up to 80 WM threads on GT2.
On Mon, 28 Mar 2011 15:22:35 -0700, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/28/2011 10:55 AM, Eric Anholt wrote: > > > Here's an idea for an SNB performance improvement from the specs. It > > says that on GT2 you should be able to use 80 threads if "WIZ Hashing > > Disable in GT_MODE register enabled". On my system (supposedly GT2), > > that bit (bit 6 of 0x20d0) is unset. In testing, with intel_reg_write > > 0x20d0 0x00400040 (it only successfully took once, I suspect due to > > FORCEWAKE, which also means that I can't necessarily trust that the > > bit was unset originally), I got only hangs from 3D. > > So, we're currently using too many threads in some cases? Could this be > related to bug #35730? In that case the failure seems to be limited to > SugarBay. I believe that's GT1, but I can never get the code names for > these chips straight. Nope, note how instead of using that original wm_max_threads value, 40 is hardcoded in the place that should have been using it. pgpkLT7zmHSEa.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
Hi Chris, have you updated this patch? I think this patch may be obsolete, as these patches http://lists.freedesktop.org/archives/intel-gfx/2011-March/009583.html do the same and much more. It is not clear yet how to prevent users from accidentally using these functions which will make the display unreadable when used carelessly. Greets, Kiste ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/lvds: Kill trying to probe LVDS using a DDC write
This fails on the Macbook for example, and Jesse reported a failure
after unloading and reloading the i915.ko module on a HP system. It
looked promising distinguishing several of the ghost LVDS, but with even
a single false positive, it cannot replace the quirk table.
Signed-off-by: Chris Wilson
Cc: Jesse Barnes
---
drivers/gpu/drm/i915/intel_lvds.c | 24
1 files changed, 0 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 86cd30b..a562bd2 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -829,25 +829,6 @@ static bool lvds_is_present_in_vbt(struct drm_device *dev,
return false;
}
-static bool intel_lvds_ddc_probe(struct drm_device *dev, u8 pin)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
- u8 buf = 0;
- struct i2c_msg msgs[] = {
- {
- .addr = 0xA0,
- .flags = 0,
- .len = 1,
- .buf = &buf,
- },
- };
- struct i2c_adapter *i2c = &dev_priv->gmbus[pin].adapter;
- /* XXX this only appears to work when using GMBUS */
- if (intel_gmbus_is_forced_bit(i2c))
- return true;
- return i2c_transfer(i2c, msgs, 1) == 1;
-}
-
/**
* intel_lvds_init - setup LVDS connectors on this device
* @dev: drm device
@@ -888,11 +869,6 @@ bool intel_lvds_init(struct drm_device *dev)
}
}
- if (!intel_lvds_ddc_probe(dev, pin)) {
- DRM_DEBUG_KMS("LVDS did not respond to DDC probe\n");
- return false;
- }
-
intel_lvds = kzalloc(sizeof(struct intel_lvds), GFP_KERNEL);
if (!intel_lvds) {
return false;
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [WIP] i965: Use up to 80 WM threads on GT2.
On Mon, 28 Mar 2011 15:37:37 -0700, Ben Widawsky wrote: > On Mon, Mar 28, 2011 at 10:55:40AM -0700, Eric Anholt wrote: > > --- > > I suspect due to > > FORCEWAKE, which also means that I can't necessarily trust that the > > bit was unset originally), I got only hangs from 3D. > > If you want to get some more possibly garbage data, you can set > forcewake from userspace, and hope the kernel doesn't unset it :). > > intel_reg_write 0xa18c 1 > # check for ack > intel_reg_read 0x130090 > > I've never tried it, but it might work at least for reading that first > bit. I'm currenty working around this with > <1301105269-23970-1-git-send-email-...@bwidawsk.net> > and a hack in the kernel to do a get() and never do a put. I'm tempted by the idea of having a kernel interface for unpriveleged interfaces for reading these regs, which would allow for non-root gpu_top in addition to doing the forcewake. It'll suck to maintain a list of unpriveleged-OK regs, though. pgpNdsRbrNP28.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Core i5 Sandybridge: "Destroyed" by kernel?
Hi guys, Well, I got my new notebook today, a Dell e6420 with Intel HD-3000 and a Core i5 processor. Anyway, I didn't like the windows which was installed (it worked at least though), so I wanted to install Linux, with quite .. strange results: First of all, the live cd i booted had stock kernel 2.6.38.0, which is quite a recent one. Booting up, when loading the modules, the screen goes black with white stripes to the right side (I took a picture you can have if you want). That was all I could see, no booting lines, no X. Well, after researching some on my 2nd machine, the screen of my laptop went black (timed out / screensaver?), and when I moved the mouse - X appeared. Although, it "flickered" a lot, and had a bunch of graphic glitches, but I was able to install Linux. After I booted again, same result: Loading modules -> laptop screen black, and white stripes to the right side. Same picture as above. Since I'm not easy to scare, I upgraded to 2.6.38.1 (i still could log in with the flickering after the screen timed out once :D), still - the same result. After a few reboots, I realized that the BIOS started to flicker a lot as well, which started to make me nervous, so I took out my Windows cd and realized - that's flickering now as well. I completely reinstalled Windows with all recent drivers - still the flickering. I tried again with openSUSE - same results. Well now, it seem as if I have to send back the Laptop, not sure if I can get guarantee on that one though, what's quite a loss, but probably I can work out something with Dell (good luck with that, I know..). What I wanted to know, are there any similar reports about this? I could not find anything about linux destroying or not even "not working" with this setup. The laptop is even supported with Ubuntu, so it "should" work I guess, but this smells really like some problem with the intel drivers. Best regards, Georg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [WIP] i965: Use up to 80 WM threads on GT2.
On 2011/3/29 6:22, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/2011 10:55 AM, Eric Anholt wrote: Here's an idea for an SNB performance improvement from the specs. It says that on GT2 you should be able to use 80 threads if "WIZ Hashing Disable in GT_MODE register enabled". On my system (supposedly GT2), that bit (bit 6 of 0x20d0) is unset. In testing, with intel_reg_write 0x20d0 0x00400040 (it only successfully took once, I suspect due to FORCEWAKE, which also means that I can't necessarily trust that the bit was unset originally), I got only hangs from 3D. So, we're currently using too many threads in some cases? Could this be related to bug #35730? In that case the failure seems to be limited to SugarBay. I believe that's GT1, but I can never get the code names for these chips straight. The system environment description section in bug #35730 already mention it's rev09 GT1 Thanks --Shuang -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2RCisACgkQX1gOwKyEAw8nRgCgnC1HMyfVwx5MLiaVF4mVzprQ oD4An2DMFJdXfYKOyvehR7x6qAQnYix6 =4m/t -END PGP SIGNATURE- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [WIP] i965: Use up to 80 WM threads on GT2.
On Mon, Mar 28, 2011 at 10:55:40AM -0700, Eric Anholt wrote: > --- > I suspect due to > FORCEWAKE, which also means that I can't necessarily trust that the > bit was unset originally), I got only hangs from 3D. If you want to get some more possibly garbage data, you can set forcewake from userspace, and hope the kernel doesn't unset it :). intel_reg_write 0xa18c 1 # check for ack intel_reg_read 0x130090 I've never tried it, but it might work at least for reading that first bit. I'm currenty working around this with <1301105269-23970-1-git-send-email-...@bwidawsk.net> and a hack in the kernel to do a get() and never do a put. Ben ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [WIP] i965: Use up to 80 WM threads on GT2.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/2011 10:55 AM, Eric Anholt wrote: > Here's an idea for an SNB performance improvement from the specs. It > says that on GT2 you should be able to use 80 threads if "WIZ Hashing > Disable in GT_MODE register enabled". On my system (supposedly GT2), > that bit (bit 6 of 0x20d0) is unset. In testing, with intel_reg_write > 0x20d0 0x00400040 (it only successfully took once, I suspect due to > FORCEWAKE, which also means that I can't necessarily trust that the > bit was unset originally), I got only hangs from 3D. So, we're currently using too many threads in some cases? Could this be related to bug #35730? In that case the failure seems to be limited to SugarBay. I believe that's GT1, but I can never get the code names for these chips straight. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2RCisACgkQX1gOwKyEAw8nRgCgnC1HMyfVwx5MLiaVF4mVzprQ oD4An2DMFJdXfYKOyvehR7x6qAQnYix6 =4m/t -END PGP SIGNATURE- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
Sorry, about the empty reply. - Original message - > On Wed, 2011-02-09 at 15:01 +, Chris Wilson wrote: > > The LVDS code ignores any connector for which it cannot find a fixed > > mode (through an EDID, vBIOS tables or the current active mode). Some > > platforms may include an LVDS header on the board and this may then be > > partnered with a panel without an EDID. This results in us ignoring the > > connector and not lighting up the panel. > > Yeah not like this. > > you want to make the command line the *last* option we use, the final > fallback. LVDS panels have EDID and VBT hardcoded modes for a good > reason, they don't work with other modes that well. You always want to > use a scaler on the LVDS panel to do modes not the native mode. So if I > have a VBT or EDID and you set video= I should get a scaled mode, not > garbage. > > So what I suspect you really want is to leave video= alone or enhance it > somehow, or maybe add i915.lvds_native_mode= parameter. Hi Chris, have you updated this patch? I have an Intel D525 (Pineview) system with HDMI port connected through an LVDS converter. The "panel timings" are the HDMI output mode, and it gets set through a BIOS option making it impossible to use the native resolution on the HDTV display. Ideally, it would be better if this hardware configuration could be quirked to represent the output as a HDMI connector, but programmed through the LVDS registers, but I'm not sure how feasible that is. At least being able to set custom timings for the fixed mode would be a great improvment. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > On Wed, 2011-02-09 at 15:01 +, Chris Wilson wrote: > > The LVDS code ignores any connector for which it cannot find a fixed > > mode (through an EDID, vBIOS tables or the current active mode). Some > > platforms may include an LVDS header on the board and this may then be > > partnered with a panel without an EDID. This results in us ignoring the > > connector and not lighting up the panel. > > Yeah not like this. > > you want to make the command line the *last* option we use, the final > fallback. LVDS panels have EDID and VBT hardcoded modes for a good > reason, they don't work with other modes that well. You always want to > use a scaler on the LVDS panel to do modes not the native mode. So if I > have a VBT or EDID and you set video= I should get a scaled mode, not > garbage. > > So what I suspect you really want is to leave video= alone or enhance it > somehow, or maybe add i915.lvds_native_mode= parameter. Hi Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] [WIP] i965: Use up to 80 WM threads on GT2.
---
Here's an idea for an SNB performance improvement from the specs. It
says that on GT2 you should be able to use 80 threads if "WIZ Hashing
Disable in GT_MODE register enabled". On my system (supposedly GT2),
that bit (bit 6 of 0x20d0) is unset. In testing, with intel_reg_write
0x20d0 0x00400040 (it only successfully took once, I suspect due to
FORCEWAKE, which also means that I can't necessarily trust that the
bit was unset originally), I got only hangs from 3D.
src/mesa/drivers/dri/i965/brw_context.c|6 +-
src/mesa/drivers/dri/i965/gen6_wm_state.c |2 +-
src/mesa/drivers/dri/intel/intel_chipset.h | 10 ++
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 9483ec6..3555e44 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -184,7 +184,11 @@ GLboolean brwCreateContext( int api,
if (intel->gen >= 6) {
brw->urb.size = 1024;
brw->vs_max_threads = 60;
- brw->wm_max_threads = 80;
+ if (IS_GT2(intel->intelScreen->deviceID)) {
+brw->wm_max_threads = 80;
+ } else {
+brw->wm_max_threads = 40;
+ }
} else if (intel->gen == 5) {
brw->urb.size = 1024;
brw->vs_max_threads = 72;
diff --git a/src/mesa/drivers/dri/i965/gen6_wm_state.c
b/src/mesa/drivers/dri/i965/gen6_wm_state.c
index 78901ec..b91e1c1 100644
--- a/src/mesa/drivers/dri/i965/gen6_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_wm_state.c
@@ -144,7 +144,7 @@ upload_wm_state(struct brw_context *brw)
dw4 |= (brw->wm.prog_data->first_curbe_grf <<
GEN6_WM_DISPATCH_START_GRF_SHIFT_0);
- dw5 |= (40 - 1) << GEN6_WM_MAX_THREADS_SHIFT;
+ dw5 |= (brw->wm.max_threads - 1) << GEN6_WM_MAX_THREADS_SHIFT;
/* CACHE_NEW_WM_PROG */
if (brw->wm.prog_data->dispatch_width == 8)
diff --git a/src/mesa/drivers/dri/intel/intel_chipset.h
b/src/mesa/drivers/dri/intel/intel_chipset.h
index 4ff9140..f7dcf47 100644
--- a/src/mesa/drivers/dri/intel/intel_chipset.h
+++ b/src/mesa/drivers/dri/intel/intel_chipset.h
@@ -125,12 +125,14 @@
/* Compat macro for intel_decode.c */
#define IS_IRONLAKE(devid) IS_GEN5(devid)
-#define IS_GEN6(devid) (devid == PCI_CHIP_SANDYBRIDGE_GT1 || \
-devid == PCI_CHIP_SANDYBRIDGE_GT2 || \
+#define IS_GT2(devid) (devid == PCI_CHIP_SANDYBRIDGE_GT2 || \
devid == PCI_CHIP_SANDYBRIDGE_GT2_PLUS || \
-devid == PCI_CHIP_SANDYBRIDGE_M_GT1 || \
devid == PCI_CHIP_SANDYBRIDGE_M_GT2 || \
-devid == PCI_CHIP_SANDYBRIDGE_M_GT2_PLUS || \
+devid == PCI_CHIP_SANDYBRIDGE_M_GT2_PLUS)
+
+#define IS_GEN6(devid) (IS_GT2(devid) || \
+devid == PCI_CHIP_SANDYBRIDGE_GT1 || \
+devid == PCI_CHIP_SANDYBRIDGE_M_GT1 || \
devid == PCI_CHIP_SANDYBRIDGE_S)
#define IS_GT1(devid) (devid == PCI_CHIP_SANDYBRIDGE_GT1 || \
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] HDMI on D525 detected as LVDS (Was: Re: YCbCr colourspace output)
On 03/28/2011 04:51 AM, Steven Newbury wrote: - Original message - I'm connecting a D525 (Pineview) based system to an older "HD" (1366x768) Phillips TV. I has a DVI connector for HD input, but whether I connect it using the VGA->DVI or HDMI->DVI the TV detects the incomming signal as from a PC and selects a "XGA" mode, limiting the screen format to aspects and resolutions it expects a PC to use; like 640x480, 800x600, 1024x768 4:3/16:10 @60Hz (always with black borders), even though the TV officially supports HDTV 720p,1080i 50/60Hz etc.. I suspect the issue lies in the assumption that HDTV equipment would have a YCbCr colourspace. Now my question is, since I can't really modify the TV firmware, is it possible to add YCbCr output to the driver, assuming the chip supports it? Okay, it's even weirder than I thought! Further testing has shown that with an analogue RGB input the frame always has a left/right borders (making it 16:10 when in "wide screen") and are restricted to 640x480, 800x600 and 1024x768, whilst the DVI-D input seems to be more resonable, except the BIOS on my board insists on configuring the HDMI port as an LVDS with BIOS configured mode timings. This wouldn't be too bad except the fixed mode in the BIOS for the native panel size (1366x768) gives a mode shifted significantly to the left (off the screen) and while the 1280x720 fits fine, the TV does a really awful job of scaling! I'm thinking this board must have an LVDS->HDMI converter so it wouldn't be suprising the driver treats it this way, even so it would be really handy to have an override to allow mode setting to adjust the apparent panel mode and so present such hardware in a useful fasion to userspace. Yes. I'm 99% positive that all "HDMI" on Pineview is actually done through LVDS->HDMI converters. Pineview doesn't natively support HDMI. Am I missing something, or does KMS only accept the BIOS provided panel timings? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] HDMI on D525 detected as LVDS (Was: Re: YCbCr colourspace output)
- Original message - > > > Am I missing something, or does KMS only accept the BIOS provided > > panel timings? > > There is a patch pending about setting LVDS parameters by hand if no or > incorrect display data is present. But the controlling options are still > being discussed as I understand it. > I just found the earlier NAK'd patch to dri-devel, having a lvds_native_mode parameter would help a lot, even better in this case would be a quirk to make the LVDS timings reprogrammable (appear as an HDMI connector) since it's actually _is_ wired to a HDMI connector! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] HDMI on D525 detected as LVDS (Was: Re: YCbCr colourspace output)
Am I missing something, or does KMS only accept the BIOS provided panel timings? There is a patch pending about setting LVDS parameters by hand if no or incorrect display data is present. But the controlling options are still being discussed as I understand it. Greets, Kiste ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] HDMI on D525 detected as LVDS (Was: Re: YCbCr colourspace output)
- Original message - > I'm connecting a D525 (Pineview) based system to an older "HD" > (1366x768) Phillips TV. I has a DVI connector for HD input, but whether > I connect it using the VGA->DVI or HDMI->DVI the TV detects the > incomming signal as from a PC and selects a "XGA" mode, limiting the > screen format to aspects and resolutions it expects a PC to use; like > 640x480, 800x600, 1024x768 4:3/16:10 @60Hz (always with black borders), > even though the TV officially supports HDTV 720p,1080i 50/60Hz etc.. I > suspect the issue lies in the assumption that HDTV equipment would have > a YCbCr colourspace. > > Now my question is, since I can't really modify the TV firmware, is it > possible to add YCbCr output to the driver, assuming the chip supports > it? Okay, it's even weirder than I thought! Further testing has shown that with an analogue RGB input the frame always has a left/right borders (making it 16:10 when in "wide screen") and are restricted to 640x480, 800x600 and 1024x768, whilst the DVI-D input seems to be more resonable, except the BIOS on my board insists on configuring the HDMI port as an LVDS with BIOS configured mode timings. This wouldn't be too bad except the fixed mode in the BIOS for the native panel size (1366x768) gives a mode shifted significantly to the left (off the screen) and while the 1280x720 fits fine, the TV does a really awful job of scaling! I'm thinking this board must have an LVDS->HDMI converter so it wouldn't be suprising the driver treats it this way, even so it would be really handy to have an override to allow mode setting to adjust the apparent panel mode and so present such hardware in a useful fasion to userspace. Am I missing something, or does KMS only accept the BIOS provided panel timings? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
