Re: Linux 2.6.31-rc7

2009-09-10 Thread Zhenyu Wang 
On 2009.08.25 21:20:18 -0700, Linus Torvalds wrote:

 And how about MacBook 2.1, which apparently also goes black?
 

Linus, sorry for reply this old thread. 

I just handed on one MacBook with 945GM, and tried to find out
the reason of black screen. It is TV detection that caused it.

MacBook routes integrated TV DAC to mini-DVI port too, like for VGA.
Our TV detect does load detect, which trys to set a mode onto TV port
and checked back its status. This TV load-detect makes the LVDS black
on MacBook.

It looks our load detect function has problem that when we pick
up one crtc, we don't check if its has a fb. During first TV detect,
choosed crtc obviously has no fb, it would fail in modesetting when
setting plane surface. This might have effect on the purpose of load-
detect process. I'll see how it should be fixed. But even if I hacked
plane setting with all zeros, screen still goes black on my MacBook,
although TV detect return is right that there's none found. 

So this blank issue is within detect process, if you try to load fbcon
or X later, setting mode is fine on LVDS. That's why build fbcon in
kernel might workaround this issue.

I don't know much about our TV detect method details, but looks like
here we should check current TV status when system start. Otherwise
it seems we can't stopping blank the screen...So I did a temp hacking
like,

diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 5b1c9e9..f3ecbaa 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1451,8 +1451,18 @@ intel_tv_detect(struct drm_connector *connector)
struct intel_output *intel_output = to_intel_output(connector);
struct intel_tv_priv *tv_priv = intel_output-dev_priv;
struct drm_encoder *encoder = intel_output-enc;
+   struct drm_i915_private *dev_priv = connector-dev-dev_private;
int dpms_mode;
int type = tv_priv-type;
+   static int first_detect = 1;
+
+   if (first_detect) {
+   first_detect = 0;
+   if (!(I915_READ(TV_CTL)  TV_ENC_ENABLE))
+   return connector_status_disconnected;
+   else
+   return connector_status_connected;
+   }
 
mode = reported_modes[0];
drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);

which makes LVDS working, but I haven't tested with mini-DVI - S-Video.
I'm not sure if this is ideal enough for this, but first get port states in
system startup for initial setup, and userspace could check and set required
config later seems sane to me, as you have also suggested to do.

This patch doesn't aim to be upstream, we may set the state in priv struct
to check boot state, but I'd like to hear others' comment about this.

thanks.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

2009-08-26 Thread Dave Airlie 
On Wed, Aug 26, 2009 at 4:26 PM, Eric Anholte...@anholt.net wrote:
 On Wed, 2009-08-26 at 13:47 +1000, Dave Airlie wrote:
 On Wed, Aug 26, 2009 at 1:33 PM, Linus
 Torvaldstorva...@linux-foundation.org wrote:
 
 
  On Wed, 26 Aug 2009, Zhenyu Wang wrote:
 
   In my experience, the BIOS setup doesn't reflect what outputs should be
   used at runtime, and certainly not the correct configuration of the
   enabled outputs.  For example, if we went to this, the giant monitor
   attached to my laptop that I actually look at would go unused.
 
  yeah, normally VBIOS startup just needs or only can driver one pipe, so
  we don't have any pre knowledge except detect everything.
 
  Umm. What's your guys point, exactly?
 
  The fact is, as-is, YOU DETECT THE WRONG OUTPUTS!
 
  If you actually detected things _right_, none of this would be an issue.
  But you don't. And you seem to have a really hard time even admitting
  that. You try to re-detect things, and you SCREW UP.

 This isn't anything to do with redetection, and in the Mac case there isn't
 even a BIOS table that you can really rely on since Apple hard coded all
 this stuff into their EFI and Mac OSX drivers.

 Now you probably get a video bios using Apples bios layer, but it also
 is most likely not telling anything close to the truth about the hw layout.

 Just because the BIOS manages to light up an output in now way effects
 whether the driver can do the same.

 
  we already have some mac relate bugs open, but please report on it so we
  do have people with hardware to try and response. We have recently got a
  MacBook, yakui is looking after the modesetting issue on it.
 
  Quite frankly, I've reported these things several times. I've been open to
  try patches. Nothing has ever come out of it.
 
  I have a Mac Mini that I reported as broken over a month ago. I have a
  Westemere I've reported as not doing any DDC probing - and that I have to
  disable the LVDS probing on entirely in order to not make KMS set up the
  display to go to a non-existent LVDS port.
 
  You claim that you detect everything, but quite frankly, you don't. The
  KMS code seems to assume that if it's a mobile chipset, it should have an
  LVDS output - and whether anything is connected to that or not is totally
  immaterial. There's clearly _zero_ detection going on.
 
  And the thing is, X seems to get it right, at least more often than KMS
  does.
 

 I'm not sure why the mac-mini hack hasn't been merged I asked for it a
 few times,
 I'd rather the proper solution was merged but that seems to not have
 happened either.

 Your complaint about needing to do the proper solution was why I never
 merged it.  It looked like a NAK to me.

I later told Keith to go ahead and send it onwards with the proviso someone
would look at doing it properly.

Granted with Linus suggestions maybe someone needs to look at it sooner.

Dave.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

2009-08-26 Thread ykzhao 
On Wed, 2009-08-26 at 11:58 +0800, Zhenyu Wang wrote:
Hi
From the config file it seems that the CONFIG_FRAMEBUFFER_CONSOLE is
set as m.
Will you please set it to y and see whether the black screen
happens?
  
Thanks.
   Yakui
 On 2009.08.25 20:33:32 -0700, Linus Torvalds wrote:
  On Wed, 26 Aug 2009, Zhenyu Wang wrote:
  
In my experience, the BIOS setup doesn't reflect what outputs should be
used at runtime, and certainly not the correct configuration of the
enabled outputs.  For example, if we went to this, the giant monitor
attached to my laptop that I actually look at would go unused.
   
   yeah, normally VBIOS startup just needs or only can driver one pipe, so
   we don't have any pre knowledge except detect everything.
  
  Umm. What's your guys point, exactly?
  
 
 We can't depend on any BIOS display config as you noted before our driver.
 And our driver does more flexible config than VBIOS does.
 
  The fact is, as-is, YOU DETECT THE WRONG OUTPUTS!
  
  If you actually detected things _right_, none of this would be an issue. 
  But you don't. And you seem to have a really hard time even admitting 
  that. You try to re-detect things, and you SCREW UP.
  
 
 We know we have problem on Mac mini, this issue has been known for a while.
 And Keith also posted patch at
   http://lists.freedesktop.org/archives/intel-gfx/2009-June/002843.html
 but I don't know the status of this now.
 
   we already have some mac relate bugs open, but please report on it so we
   do have people with hardware to try and response. We have recently got a
   MacBook, yakui is looking after the modesetting issue on it.
  
  Quite frankly, I've reported these things several times. I've been open to 
  try patches. Nothing has ever come out of it. 
  
  I have a Mac Mini that I reported as broken over a month ago. I have a 
  Westemere I've reported as not doing any DDC probing - and that I have to 
  disable the LVDS probing on entirely in order to not make KMS set up the 
  display to go to a non-existent LVDS port.
  
  You claim that you detect everything, but quite frankly, you don't. The 
  KMS code seems to assume that if it's a mobile chipset, it should have an 
  LVDS output - and whether anything is connected to that or not is totally 
  immaterial. There's clearly _zero_ detection going on.
  
 
 We've tried many ways to detect LVDS, but none is stable or actually work for
 every chip. But now we have DMI quirks for some known no LVDS machine 
 (including
 Mac mini), and we detect through ACPI LID object for LVDS exist. 
 


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

2009-08-26 Thread Linus Torvalds 


On Wed, 26 Aug 2009, Dave Airlie wrote:
 
 3. Here's the thing, we do detect something has changed, we detect we no
 longer have a monitor connected on the mac mini because the routing
 for the DDC pins is insane and need special treatment in the driver.

That's the second thing - DDC in general seems to be _very_ flaky on intel 
chips.

And I don't mean that in a Mac Mini kind of sense. I'm seeing in on 
other machines. Here's my old EeePC 701:

[drm] Initialized drm 1.1.0 20060810
i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16
i915 :00:02.0: setting latency timer to 64
i2c-adapter i2c-1: unable to read EDID block.
i915 :00:02.0: LVDS-1: no EDID data
[drm] DAC-6: set mode 640x480 0
i2c-adapter i2c-1: unable to read EDID block.
i915 :00:02.0: LVDS-1: no EDID data
[drm] TV-11: set mode NTSC 480i 0
allocated 800x480 fb: 0x007df000, bo f735b540
[drm] LVDS-8: set mode 800x480 15
Console: switching to colour frame buffer device 100x30

and quite frankly, I suspect you've never ever actually googled for no 
EDID data, because if you had, you'd have seen that this is quite common.

And yes, the response of KMS seems to be ok, I failed at EDID, so I'll 
just assume something isn't there. And then usually it picks LVDS 
instead, if it finds a VBT table for it. Which happens to work fine on 
most laptops, but it's still just a random heuristic.

And yes, for all I know it's because the display really doesn't do any 
EDID.

And that really kind of is the point - it doesn't even matter whether the 
problem is the Intel driver doing something wrong on the EDID front (which 
it has done quite often - ranging from just looking at the wrong port, to 
not setting the right bits to make bit-banging i2c work AT ALL), or 
whether the problem is that the hardware is wired up oddly (Mac Mini) or 
whether it's the hardware simply not doign EDID at all (maybe my EeePC? Or 
a really old VGA monitor, or whatever).

In all three cases the end result is no EDID, but regardless of that, 
the correct action is basically _never_ to say ok, I'll just assume that 
the display is on connector XYZ regardless of what the state of the 
graphics chip is.

 so yes I think do better at failing is what is needed, its still
 failing but its more user friendly fail.

Yes. If something fails (oops, I can't seem EDID for any connector), I 
wish KMS would fail way better than just default to some crazy setup. The 
failure mode should be to at least drive whatever the BIOS enabled.

Linus

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

2009-08-26 Thread Jesse Barnes 
On Wed, 26 Aug 2009 10:12:14 -0700 (PDT)
Linus Torvalds torva...@linux-foundation.org wrote:
 In all three cases the end result is no EDID, but regardless of
 that, the correct action is basically _never_ to say ok, I'll just
 assume that the display is on connector XYZ regardless of what the
 state of the graphics chip is.

Yeah, that's normal.  Most builtin panels don't have EDIDs.  Failures
on attached monitors are potentially more serious.

  so yes I think do better at failing is what is needed, its still
  failing but its more user friendly fail.
 
 Yes. If something fails (oops, I can't seem EDID for any
 connector), I wish KMS would fail way better than just default to
 some crazy setup. The failure mode should be to at least drive
 whatever the BIOS enabled.

Right, we need to improve our detection heuristics.  We've recently
added some to catch non-existent LVDS displays, but currently don't
have any for VGA.  Using the current configuration as a guide is a
reasonable addition...

-- 
Jesse Barnes, Intel Open Source Technology Center

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

2009-08-25 Thread Linus Torvalds 


On Tue, 25 Aug 2009, mailing54 wrote:

 Linus Torvalds schrieb:
  Are you using the same config? It sounds very much like your -rc7 problems
  are due to the Intel KMS (kernel mode setting) driver, which I know has had
  problems on at least Mac Mini's. And I wonder if the -rc6 kernel deb used
  different config options and didn't enable KMS, for example. Because I don't
  think anything actually changed in the KMS code itself between rc6 and rc7.
   
 Not sure what settings to look for, but this looks like you are completely
 correct:
 
 tob...@tbox:~$ cat /boot/config-2.6.31-020631rc6-generic | grep KMS
 # CONFIG_DRM_I915_KMS is not set
 # CONFIG_DRM_RADEON_KMS is not set
 tob...@tbox:~$ cat /boot/config-2.6.31-020631rc7-generic | grep KMS
 CONFIG_DRM_I915_KMS=y
 CONFIG_DRM_RADEON_KMS=y

Yeah, so it's i915 kms.

You can disable it dynamically at boot time with the 

i915.modeset=0

kernel command line (or I guess with nomodeset too, for that matter, 
which should disable both i915 and radeom kms).

However, the problem remains that KMS gets the output wrong, in ways that 
clearly X does not. Eric - it's clearly not just Mac Mini and my 
experimental machine that have problems, but also a Macbook 2.1.

I wonder why the Intel KMS logic doesn't look at which output was driven 
before it got invoked. Instead, it seems to want to try to detect 
everything from scratch, even though we should be able to assume that if 
you boot from BIOS (or EFI, for that matter), the current state of the 
graphics pipeline is likely meaningful.

And clearly distros are trying to enable this. Which means that this is 
getting way more important to solve.

Linus

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

2009-08-25 Thread Eric Anholt 
On Tue, 2009-08-25 at 15:07 -0700, Linus Torvalds wrote:
 
 On Tue, 25 Aug 2009, mailing54 wrote:
 
  Linus Torvalds schrieb:
   Are you using the same config? It sounds very much like your -rc7 problems
   are due to the Intel KMS (kernel mode setting) driver, which I know has 
   had
   problems on at least Mac Mini's. And I wonder if the -rc6 kernel deb used
   different config options and didn't enable KMS, for example. Because I 
   don't
   think anything actually changed in the KMS code itself between rc6 and 
   rc7.

  Not sure what settings to look for, but this looks like you are completely
  correct:
  
  tob...@tbox:~$ cat /boot/config-2.6.31-020631rc6-generic | grep KMS
  # CONFIG_DRM_I915_KMS is not set
  # CONFIG_DRM_RADEON_KMS is not set
  tob...@tbox:~$ cat /boot/config-2.6.31-020631rc7-generic | grep KMS
  CONFIG_DRM_I915_KMS=y
  CONFIG_DRM_RADEON_KMS=y
 
 Yeah, so it's i915 kms.
 
 You can disable it dynamically at boot time with the 
 
   i915.modeset=0
 
 kernel command line (or I guess with nomodeset too, for that matter, 
 which should disable both i915 and radeom kms).
 
 However, the problem remains that KMS gets the output wrong, in ways that 
 clearly X does not. Eric - it's clearly not just Mac Mini and my 
 experimental machine that have problems, but also a Macbook 2.1.
 
 I wonder why the Intel KMS logic doesn't look at which output was driven 
 before it got invoked. Instead, it seems to want to try to detect 
 everything from scratch, even though we should be able to assume that if 
 you boot from BIOS (or EFI, for that matter), the current state of the 
 graphics pipeline is likely meaningful.

In my experience, the BIOS setup doesn't reflect what outputs should be
used at runtime, and certainly not the correct configuration of the
enabled outputs.  For example, if we went to this, the giant monitor
attached to my laptop that I actually look at would go unused.

 And clearly distros are trying to enable this. Which means that this is 
 getting way more important to solve.

Yes, please open a bug on bugs.freedesktop.org and set severity=critical
-- the people working on modesetting should pick it up and take a look
at it.

For some of the DDC bugs, David Müller has an interesting-looking patch
to parse the BIOS's tables describing what DDC pin is used for VGA on
852, though it looks like it should be usable on much more.  I was
hoping the modesetting guys would review it and ack, but no response so
far.

-- 
Eric Anholt
e...@anholt.net eric.anh...@intel.com




signature.asc
Description: This is a digitally signed message part
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

2009-08-25 Thread Zhenyu Wang 
On 2009.08.25 15:33:57 -0700, Eric Anholt wrote:
  However, the problem remains that KMS gets the output wrong, in ways that 
  clearly X does not. Eric - it's clearly not just Mac Mini and my 
  experimental machine that have problems, but also a Macbook 2.1.
  
  I wonder why the Intel KMS logic doesn't look at which output was driven 
  before it got invoked. Instead, it seems to want to try to detect 
  everything from scratch, even though we should be able to assume that if 
  you boot from BIOS (or EFI, for that matter), the current state of the 
  graphics pipeline is likely meaningful.
 
 In my experience, the BIOS setup doesn't reflect what outputs should be
 used at runtime, and certainly not the correct configuration of the
 enabled outputs.  For example, if we went to this, the giant monitor
 attached to my laptop that I actually look at would go unused.
 

yeah, normally VBIOS startup just needs or only can driver one pipe, so
we don't have any pre knowledge except detect everything.

  And clearly distros are trying to enable this. Which means that this is 
  getting way more important to solve.
 
 Yes, please open a bug on bugs.freedesktop.org and set severity=critical
 -- the people working on modesetting should pick it up and take a look
 at it.
 

we already have some mac relate bugs open, but please report on it so we
do have people with hardware to try and response. We have recently got a
MacBook, yakui is looking after the modesetting issue on it.

 For some of the DDC bugs, David Müller has an interesting-looking patch
 to parse the BIOS's tables describing what DDC pin is used for VGA on
 852, though it looks like it should be usable on much more.  I was
 hoping the modesetting guys would review it and ack, but no response so
 far.
 

We should also have floating patch on that, hope we'll prepare and cleanup
the patches for mac soon.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

2009-08-25 Thread Linus Torvalds 


On Wed, 26 Aug 2009, Zhenyu Wang wrote:

  In my experience, the BIOS setup doesn't reflect what outputs should be
  used at runtime, and certainly not the correct configuration of the
  enabled outputs.  For example, if we went to this, the giant monitor
  attached to my laptop that I actually look at would go unused.
 
 yeah, normally VBIOS startup just needs or only can driver one pipe, so
 we don't have any pre knowledge except detect everything.

Umm. What's your guys point, exactly?

The fact is, as-is, YOU DETECT THE WRONG OUTPUTS!

If you actually detected things _right_, none of this would be an issue. 
But you don't. And you seem to have a really hard time even admitting 
that. You try to re-detect things, and you SCREW UP.

 we already have some mac relate bugs open, but please report on it so we
 do have people with hardware to try and response. We have recently got a
 MacBook, yakui is looking after the modesetting issue on it.

Quite frankly, I've reported these things several times. I've been open to 
try patches. Nothing has ever come out of it. 

I have a Mac Mini that I reported as broken over a month ago. I have a 
Westemere I've reported as not doing any DDC probing - and that I have to 
disable the LVDS probing on entirely in order to not make KMS set up the 
display to go to a non-existent LVDS port.

You claim that you detect everything, but quite frankly, you don't. The 
KMS code seems to assume that if it's a mobile chipset, it should have an 
LVDS output - and whether anything is connected to that or not is totally 
immaterial. There's clearly _zero_ detection going on.

And the thing is, X seems to get it right, at least more often than KMS 
does. 

Linus

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

2009-08-25 Thread Dave Airlie 
On Wed, Aug 26, 2009 at 1:33 PM, Linus
Torvaldstorva...@linux-foundation.org wrote:


 On Wed, 26 Aug 2009, Zhenyu Wang wrote:

  In my experience, the BIOS setup doesn't reflect what outputs should be
  used at runtime, and certainly not the correct configuration of the
  enabled outputs.  For example, if we went to this, the giant monitor
  attached to my laptop that I actually look at would go unused.

 yeah, normally VBIOS startup just needs or only can driver one pipe, so
 we don't have any pre knowledge except detect everything.

 Umm. What's your guys point, exactly?

 The fact is, as-is, YOU DETECT THE WRONG OUTPUTS!

 If you actually detected things _right_, none of this would be an issue.
 But you don't. And you seem to have a really hard time even admitting
 that. You try to re-detect things, and you SCREW UP.

This isn't anything to do with redetection, and in the Mac case there isn't
even a BIOS table that you can really rely on since Apple hard coded all
this stuff into their EFI and Mac OSX drivers.

Now you probably get a video bios using Apples bios layer, but it also
is most likely not telling anything close to the truth about the hw layout.

Just because the BIOS manages to light up an output in now way effects
whether the driver can do the same.


 we already have some mac relate bugs open, but please report on it so we
 do have people with hardware to try and response. We have recently got a
 MacBook, yakui is looking after the modesetting issue on it.

 Quite frankly, I've reported these things several times. I've been open to
 try patches. Nothing has ever come out of it.

 I have a Mac Mini that I reported as broken over a month ago. I have a
 Westemere I've reported as not doing any DDC probing - and that I have to
 disable the LVDS probing on entirely in order to not make KMS set up the
 display to go to a non-existent LVDS port.

 You claim that you detect everything, but quite frankly, you don't. The
 KMS code seems to assume that if it's a mobile chipset, it should have an
 LVDS output - and whether anything is connected to that or not is totally
 immaterial. There's clearly _zero_ detection going on.

 And the thing is, X seems to get it right, at least more often than KMS
 does.


I'm not sure why the mac-mini hack hasn't been merged I asked for it a
few times,
I'd rather the proper solution was merged but that seems to not have
happened either.

You have two special cases here,
a) mac mini - apple hw, needs hacks to workaround the fact that they
do something
nobody else does with the hw and then don't tell you about it in the
hw. the hack
from userspace should have been ported to the kernel but I keep not seeing it.

b) pre-production SDV hardware for a mobile chipset without LVDS,
here's both pieces
you get to keep them. LVDS isn't detectable on any hw, the sanity
assumption so far
are you have a mobile chipset you must have LVDS, you have an ACPI lid
button you
might have LVDS. You cannot reliably detect LVDS since DDC on LVDS panels isn't
mandatory. most BIOSes have an LVDS table, guess what I'd bet your BIOS claims
you have LVDS. So yes it nice you get free shiny hw but if it doesn't
work, its not nice
to give out about it.

Dave.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

2009-08-25 Thread Zhenyu Wang 
On 2009.08.25 20:33:32 -0700, Linus Torvalds wrote:
 On Wed, 26 Aug 2009, Zhenyu Wang wrote:
 
   In my experience, the BIOS setup doesn't reflect what outputs should be
   used at runtime, and certainly not the correct configuration of the
   enabled outputs.  For example, if we went to this, the giant monitor
   attached to my laptop that I actually look at would go unused.
  
  yeah, normally VBIOS startup just needs or only can driver one pipe, so
  we don't have any pre knowledge except detect everything.
 
 Umm. What's your guys point, exactly?
 

We can't depend on any BIOS display config as you noted before our driver.
And our driver does more flexible config than VBIOS does.

 The fact is, as-is, YOU DETECT THE WRONG OUTPUTS!
 
 If you actually detected things _right_, none of this would be an issue. 
 But you don't. And you seem to have a really hard time even admitting 
 that. You try to re-detect things, and you SCREW UP.
 

We know we have problem on Mac mini, this issue has been known for a while.
And Keith also posted patch at
http://lists.freedesktop.org/archives/intel-gfx/2009-June/002843.html
but I don't know the status of this now.

  we already have some mac relate bugs open, but please report on it so we
  do have people with hardware to try and response. We have recently got a
  MacBook, yakui is looking after the modesetting issue on it.
 
 Quite frankly, I've reported these things several times. I've been open to 
 try patches. Nothing has ever come out of it. 
 
 I have a Mac Mini that I reported as broken over a month ago. I have a 
 Westemere I've reported as not doing any DDC probing - and that I have to 
 disable the LVDS probing on entirely in order to not make KMS set up the 
 display to go to a non-existent LVDS port.
 
 You claim that you detect everything, but quite frankly, you don't. The 
 KMS code seems to assume that if it's a mobile chipset, it should have an 
 LVDS output - and whether anything is connected to that or not is totally 
 immaterial. There's clearly _zero_ detection going on.
 

We've tried many ways to detect LVDS, but none is stable or actually work for
every chip. But now we have DMI quirks for some known no LVDS machine (including
Mac mini), and we detect through ACPI LID object for LVDS exist. 

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: Digital signature
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

2009-08-25 Thread Linus Torvalds 


On Wed, 26 Aug 2009, Dave Airlie wrote:
 
  If you actually detected things _right_, none of this would be an issue.
  But you don't. And you seem to have a really hard time even admitting
  that. You try to re-detect things, and you SCREW UP.
 
 This isn't anything to do with redetection, and in the Mac case there isn't
 even a BIOS table that you can really rely on since Apple hard coded all
 this stuff into their EFI and Mac OSX drivers.

That's really my point.

There _is_ one sort of detection you could do: look at the actual state of 
the graphics chip.

In other words, exactly the case you mention: don't trust any BIOS tables 
(they may not exist, and they _are_ broken in many cases) or silly EFI 
information (I guarantee that any firmware info will eventually be buggy: 
EFI is in no way going to be magically less buggy than BIOS tables have 
been).

So what's left? You can still look at how the chip was programmed. If it's 
driving the VGA port, you can be pretty sure that there's a monitor 
attached. Sure, there might be something _else_ attached too, and I'm not 
saying that you cannot try to probe other things, but right now it seems 
that KMS totally throws away a free - and fairly reliable - piece of 
information. And replaces it with very unreliable information that 
definitely doesn't work.

I'm all for looking at many different places to find 'the truth', but I'm 
very unhappy with KMS looks into BIOS tables, decides that there's a LVDS 
panel attached (there isn't), and then disables the VGA port that drives 
the monitor.

That doesn't help _anybody_. It just results in a black screen. And I 
guarantee that this happens on several pieces of hardware, and no, it's 
not all just crap Apple and EFI. One of the pieces of hardware it 
happens on is an Intel-only machine. Intel hardware, Intel firmware, Intel 
motherboard, Intel _everything_. And yes, KMS decides to drive a 
nonexistent LVDS display, rather than the one that the BIOS correctly 
booted up with.

 Just because the BIOS manages to light up an output in now way effects
 whether the driver can do the same.

.. but if the BIOS drives one output, that should be a damn big hint that 
you shouldn't then just randomly pick another one!

It sure as hell is a bigger hint than the ones you're using right now. 
Which is kind of my point here. Why are you arguing against a known bug? 

 I'm not sure why the mac-mini hack hasn't been merged I asked for it a
 few times,
 I'd rather the proper solution was merged but that seems to not have
 happened either.

I want to repeat: it's not just Mac Mini. 

 You have two special cases here,
 a) mac mini - apple hw, needs hacks to workaround the fact that they do 
 something nobody else does with the hw and then don't tell you about it 
 in the hw. the hack from userspace should have been ported to the kernel 
 but I keep not seeing it.

The thing is, the BIOS _does_ report it to the hardware: you could just 
read the hardware registers.

But no. Instead the Intel KMS code discards the hardware registers, and 
reads the BIOS tables instead, finds a LVDS entry there, and uses that - 
and disconnects the entry that _was_ driving the monitor.

Really. Do you seriously believe that because you found some random tables 
in the BIOS memory, it's more reliable than oh, the BIOS set the hardware 
up to drive the SVDO output?

That's what I find irritating. We _know_ BIOS tables are random crap. We 
_know_ they are way less reliable than just asking the hardware where it 
is. But KMS still trusts the VBT data more than the fact that the chip has 
been programmed to output DVI/SVDO output.

 b) pre-production SDV hardware for a mobile chipset without LVDS, here's 
 both pieces you get to keep them. LVDS isn't detectable on any hw, the 
 sanity assumption so far are you have a mobile chipset you must have 
 LVDS, you have an ACPI lid button you might have LVDS.

Again, you say that, but you have absolutely nothing to back it up with.

Here's a counter-argument: we _know_ that it's not detectable whether 
there's an LVDS panel is attached or not. So what should we do? Should we 
turn off the VGA1 connection that we can see that the BIOS programmed, and 
set things up for LVDS instead?

That's f*cking _stupid_. Go ahead and program the LVDS panel *too*, but 
don't turn off the SDVO (or whatever) output that was also active!

And quite frankly, if the BIOS didn't turn on the panel, then maybe the 
kernel shouldn't either. At least not until it gets a lid open event. So 
even the go ahead and program LVDS too part is quite debatable.

In other words: it would be a lot saner to just keep whatever output mode 
that the machine booted with. Then, change it ONLY IF YOU DETECT SOMETHING 
ACTUALLY CHANGING.

Linus

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report

Re: Linux 2.6.31-rc7

2009-08-25 Thread Linus Torvalds 


On Wed, 26 Aug 2009, Zhenyu Wang wrote:
 
 We can't depend on any BIOS display config as you noted before our driver.

But you do. You depend on the even _less_ reliable existence of a VBT 
table.

 And our driver does more flexible config than VBIOS does.

If by flexible you mean doesn't work in many more ways, then yes.

I have never EVER found a BIOS that didn't output to at least _some_ 
screen that is connected. That's fairly damn fundamental. Yet that is 
exactly what KMS screws up on some hardware right now.

Trust me, flexible is not the right word. 

 We know we have problem on Mac mini, this issue has been known for a while.
 And Keith also posted patch at
   http://lists.freedesktop.org/archives/intel-gfx/2009-June/002843.html
 but I don't know the status of this now.

And how about MacBook 2.1, which apparently also goes black?

And the Westmere thing? 

 We've tried many ways to detect LVDS, but none is stable or actually work for
 every chip. But now we have DMI quirks for some known no LVDS machine 
 (including
 Mac mini), and we detect through ACPI LID object for LVDS exist. 

And dammit, if you cannot detect it, then don't try.

You'd actually be better off not trying your random crud, and instead
 - leave whatever connection the BIOS set up
 - let the user _tell_ you about other ones.

If you cannot reliably detect something, don't go off and use some random 
number generator. And quite frankly, depending on BIOS tables _is_ a 
random number generator. It may be that you just haven't learnt that yet, 
but maybe you could work on ACPI for a while to see what I mean.

Right now, there's not even any way to _override_ your incorrect guesses. 

So I can say don't do mode-setting at all, but I can't say use SVDO at 
1680x1050. So my screen goes black. And I happen to be in the enviable 
position of having known about the Mac Mini issues and the KMS thing - 
think about what happens to people that just try a new distro kernel, and 
suddenly there's nothing on the screen. 

Linus

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

2009-08-25 Thread Dave Airlie 
On Wed, Aug 26, 2009 at 2:13 PM, Linus
Torvaldstorva...@linux-foundation.org wrote:


 On Wed, 26 Aug 2009, Dave Airlie wrote:
 
  If you actually detected things _right_, none of this would be an issue.
  But you don't. And you seem to have a really hard time even admitting
  that. You try to re-detect things, and you SCREW UP.

 This isn't anything to do with redetection, and in the Mac case there isn't
 even a BIOS table that you can really rely on since Apple hard coded all
 this stuff into their EFI and Mac OSX drivers.

 That's really my point.

 There _is_ one sort of detection you could do: look at the actual state of
 the graphics chip.

 In other words, exactly the case you mention: don't trust any BIOS tables
 (they may not exist, and they _are_ broken in many cases) or silly EFI
 information (I guarantee that any firmware info will eventually be buggy:
 EFI is in no way going to be magically less buggy than BIOS tables have
 been).

 So what's left? You can still look at how the chip was programmed. If it's
 driving the VGA port, you can be pretty sure that there's a monitor
 attached. Sure, there might be something _else_ attached too, and I'm not
 saying that you cannot try to probe other things, but right now it seems
 that KMS totally throws away a free - and fairly reliable - piece of
 information. And replaces it with very unreliable information that
 definitely doesn't work.

 I'm all for looking at many different places to find 'the truth', but I'm
 very unhappy with KMS looks into BIOS tables, decides that there's a LVDS
 panel attached (there isn't), and then disables the VGA port that drives
 the monitor.

 That doesn't help _anybody_. It just results in a black screen. And I
 guarantee that this happens on several pieces of hardware, and no, it's
 not all just crap Apple and EFI. One of the pieces of hardware it
 happens on is an Intel-only machine. Intel hardware, Intel firmware, Intel
 motherboard, Intel _everything_. And yes, KMS decides to drive a
 nonexistent LVDS display, rather than the one that the BIOS correctly
 booted up with.

 Just because the BIOS manages to light up an output in now way effects
 whether the driver can do the same.

 .. but if the BIOS drives one output, that should be a damn big hint that
 you shouldn't then just randomly pick another one!

 It sure as hell is a bigger hint than the ones you're using right now.
 Which is kind of my point here. Why are you arguing against a known bug?

 I'm not sure why the mac-mini hack hasn't been merged I asked for it a
 few times,
 I'd rather the proper solution was merged but that seems to not have
 happened either.

 I want to repeat: it's not just Mac Mini.

 You have two special cases here,
 a) mac mini - apple hw, needs hacks to workaround the fact that they do
 something nobody else does with the hw and then don't tell you about it
 in the hw. the hack from userspace should have been ported to the kernel
 but I keep not seeing it.

 The thing is, the BIOS _does_ report it to the hardware: you could just
 read the hardware registers.

 But no. Instead the Intel KMS code discards the hardware registers, and
 reads the BIOS tables instead, finds a LVDS entry there, and uses that -
 and disconnects the entry that _was_ driving the monitor.

 Really. Do you seriously believe that because you found some random tables
 in the BIOS memory, it's more reliable than oh, the BIOS set the hardware
 up to drive the SVDO output?

 That's what I find irritating. We _know_ BIOS tables are random crap. We
 _know_ they are way less reliable than just asking the hardware where it
 is. But KMS still trusts the VBT data more than the fact that the chip has
 been programmed to output DVI/SVDO output.

 b) pre-production SDV hardware for a mobile chipset without LVDS, here's
 both pieces you get to keep them. LVDS isn't detectable on any hw, the
 sanity assumption so far are you have a mobile chipset you must have
 LVDS, you have an ACPI lid button you might have LVDS.

 Again, you say that, but you have absolutely nothing to back it up with.

 Here's a counter-argument: we _know_ that it's not detectable whether
 there's an LVDS panel is attached or not. So what should we do? Should we
 turn off the VGA1 connection that we can see that the BIOS programmed, and
 set things up for LVDS instead?

 That's f*cking _stupid_. Go ahead and program the LVDS panel *too*, but
 don't turn off the SDVO (or whatever) output that was also active!

 And quite frankly, if the BIOS didn't turn on the panel, then maybe the
 kernel shouldn't either. At least not until it gets a lid open event. So
 even the go ahead and program LVDS too part is quite debatable.

 In other words: it would be a lot saner to just keep whatever output mode
 that the machine booted with. Then, change it ONLY IF YOU DETECT SOMETHING
 ACTUALLY CHANGING.

So most of your arguments are valid and someone at Intel should probably
investigate it.

Some points though:
1. I know