Re: Fixing X220 Video The Right Way

2014-01-30 Thread Adrian Chadd 
So now that i have everything else working on this x230, I'm taking a
fresh look at the acpi brightness support.

I'm in the same boat - only PEG works. But I have integrated graphics
only, rather than both integrated and nvidia graphics.

A cursory reading of the linux acpi and video / video-detect code
doesn't show anything terribly obvious. I may end up downloading and
booting ubuntu on USB at some point to see what the ACPI device tree
looks like, in case they are somehow linking vgapci0 correctly to
SB.PCI0.PEG.VID.

Any other ideaS?


-a
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-08-10 Thread Adrian Chadd 
when did it start working?


-adrian

On 9 August 2013 20:10, matt sendtom...@gmail.com wrote:
 hw.acpi.reset_video used to send this machine X220 into a reboot loop,
 with flashing thinklight. Interesting that it no longer causes this
 problem. I kind of paused since the trackpad sucks so much in X.

 I think since ssh still works, that just the display or graphics port
 is off.

 It may be worth trying to do some acpi_calls via ssh to try to hack
 the display back on...

 Matt

 On 08/09/13 08:57, John Baldwin wrote:
 On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote:
 Hi!

 Hm, resurrecting this thread, I'll try this on my X230 tomorrow
 and see if it makes the (non-xorg, console only) video work on
 resume.

 If it does, what will it take to automatically determine that
 this kind of work-around is needed?


 This does not affect suspend/resume.  It only fixes LCD brightness
 handling via acpi_video(4).


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-08-10 Thread matt 
Not sure that it did :)

I tried it once early on, and it concerned me enough I never tried
again. It was clearly in a violently erroneous state!

At one point, X *could* resume the display. This makes me think the
problem is solved via the graphics chip state, but it could be an
acpi thing.

I can't remember if I ever tried to startx after the resume on the
blind console.

Matt

On 08/09/13 23:00, Adrian Chadd wrote:
 when did it start working?
 
 
 -adrian
 
 On 9 August 2013 20:10, matt sendtom...@gmail.com wrote:
 hw.acpi.reset_video used to send this machine X220 into a reboot
 loop, with flashing thinklight. Interesting that it no longer
 causes this problem. I kind of paused since the trackpad sucks so
 much in X.
 
 I think since ssh still works, that just the display or graphics
 port is off.
 
 It may be worth trying to do some acpi_calls via ssh to try to
 hack the display back on...
 
 Matt
 
 On 08/09/13 08:57, John Baldwin wrote:
 On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote:
 Hi!
 
 Hm, resurrecting this thread, I'll try this on my X230
 tomorrow and see if it makes the (non-xorg, console only)
 video work on resume.
 
 If it does, what will it take to automatically determine
 that this kind of work-around is needed?
 
 
 This does not affect suspend/resume.  It only fixes LCD
 brightness handling via acpi_video(4).
 
 
 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-08-09 Thread Adrian Chadd 
Hi!

Hm, resurrecting this thread, I'll try this on my X230 tomorrow and
see if it makes the (non-xorg, console only) video work on resume.

If it does, what will it take to automatically determine that this
kind of work-around is needed?

Thanks!


-adrian


On 14 June 2013 16:00, matt sendtom...@gmail.com wrote:
 On 06/14/13 08:39, John Baldwin wrote:

 I got this to work by using 4 backslashes.  At that point the patch
 worked. (I recently got access to an X220.)  I get a local APIC
 error each time I adjust the brightness though (probably the BIOS
 is doing something wonky).



 That's awesome! I've asked -CURRENT about the

 I tried single quotes, double quotes, double backslash, and I meant to
 try ascii escapes next :)

 I'm glad you got this working, it makes the X220 (and probably other
 laptops with similar issues) more usable on FreeBSD.

 I'll have to bring my X220 back up to current and start looking at
 sleep issues next.

 Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-08-09 Thread John Baldwin 
On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote:
 Hi!
 
 Hm, resurrecting this thread, I'll try this on my X230 tomorrow and
 see if it makes the (non-xorg, console only) video work on resume.
 
 If it does, what will it take to automatically determine that this
 kind of work-around is needed?


This does not affect suspend/resume.  It only fixes LCD brightness
handling via acpi_video(4).

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-08-09 Thread matt 
hw.acpi.reset_video used to send this machine X220 into a reboot loop,
with flashing thinklight. Interesting that it no longer causes this
problem. I kind of paused since the trackpad sucks so much in X.

I think since ssh still works, that just the display or graphics port
is off.

It may be worth trying to do some acpi_calls via ssh to try to hack
the display back on...

Matt

On 08/09/13 08:57, John Baldwin wrote:
 On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote:
 Hi!
 
 Hm, resurrecting this thread, I'll try this on my X230 tomorrow
 and see if it makes the (non-xorg, console only) video work on
 resume.
 
 If it does, what will it take to automatically determine that
 this kind of work-around is needed?
 
 
 This does not affect suspend/resume.  It only fixes LCD brightness 
 handling via acpi_video(4).
 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way (and trying to apply the same fix to X121e)

2013-07-09 Thread John Baldwin 
On Monday, July 08, 2013 4:41:28 am Matthias Petermann wrote:
 
 Hello,
 
 I applied the patch, trying to get brightness controls for my X121e.
 
 But it looks like I need a different loader.conf setting.
 
  hw.pci0.0.2.0.handle=_SB_.PCI0.PEG.VID
 
 doesn't work. In my ASl there is only one device providing DOD / DOS:
 
 Scope (_SB.PCI0)
   {
   Device (GFX0)
   {
   Name (_ADR, 0x0002)  // _ADR: Address
   Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output  
 Switching
   {
   Store (And (Arg0, 0x07), DSEN)
   If (LEqual (And (Arg0, 0x03), Zero))
   {
   If (CondRefOf (HDOS))
   {
   HDOS ()
   }
   }
   }
 
   Method (_DOD, 0, NotSerialized)  // _DOD: Display Output 
Devices
   {
   If (CondRefOf (IDAB))
   {
   IDAB ()
   }
   Else
   {

So this is the \_SB_.PCI0.GFX0 device.  However, you should kldload acpi_video
and see if it already attaches to this device (devinfo -v can be helpful here 
as it will show the ACPI handle of the parent of the acpi_video device).  If 
it does, then this patch can't help you.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way (and trying to apply the same fix to X121e)

2013-07-09 Thread Matthias Petermann 

Am 09.07.2013 17:56, schrieb John Baldwin:

On Monday, July 08, 2013 4:41:28 am Matthias Petermann wrote:

Hello,

I applied the patch, trying to get brightness controls for my X121e.

But it looks like I need a different loader.conf setting.

  hw.pci0.0.2.0.handle=_SB_.PCI0.PEG.VID

doesn't work. In my ASl there is only one device providing DOD / DOS:

Scope (_SB.PCI0)
   {
   Device (GFX0)
   {
   Name (_ADR, 0x0002)  // _ADR: Address
   Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output
Switching
   {
   Store (And (Arg0, 0x07), DSEN)
   If (LEqual (And (Arg0, 0x03), Zero))
   {
   If (CondRefOf (HDOS))
   {
   HDOS ()
   }
   }
   }

   Method (_DOD, 0, NotSerialized)  // _DOD: Display Output

Devices

   {
   If (CondRefOf (IDAB))
   {
   IDAB ()
   }
   Else
   {

So this is the \_SB_.PCI0.GFX0 device.  However, you should kldload acpi_video
and see if it already attaches to this device (devinfo -v can be helpful here
as it will show the ACPI handle of the parent of the acpi_video device).  If
it does, then this patch can't help you.


Hi John,

thanks for this hint. After kldload acpi_video devinfo -v shows the 
following (truncated):


nexus0
  acpi0
  pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0
  pci0
hostb0 pnpinfo vendor=0x8086 device=0x0104 subvendor=0x17aa 
subdevice=0x21ed class=0x06 at slot=0 function=0
vgapci0 pnpinfo vendor=0x8086 device=0x0116 
subvendor=0x17aa subdevice=0x21ed class=0x03 at slot=2 function=0 
handle=\_SB_.PCI0.GFX0

  agp0
  drm0
  drmn0
  acpi_video0

Assuming the patch cannot help me, do you have an idea what I could 
check next?

I can control the brightness with
acpi_call -p '\VBRU'
acpi_call -p '\VBRD'

https://d2ux.org/owncloud/public.php?service=filest=7022f90cea5e48da7fa65806c0d66091

Regards,
Matthias
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way (and trying to apply the same fix to X121e)

2013-07-08 Thread Matthias Petermann 


Hello,

I applied the patch, trying to get brightness controls for my X121e.

But it looks like I need a different loader.conf setting.

 hw.pci0.0.2.0.handle=_SB_.PCI0.PEG.VID

doesn't work. In my ASl there is only one device providing DOD / DOS:

Scope (_SB.PCI0)
  {
  Device (GFX0)
  {
  Name (_ADR, 0x0002)  // _ADR: Address
  Method (_DOS, 1, NotSerialized)  // _DOS: Disable  
Output Switching

  {
  Store (And (Arg0, 0x07), DSEN)
  If (LEqual (And (Arg0, 0x03), Zero))
  {
  If (CondRefOf (HDOS))
  {
  HDOS ()
  }
  }
  }

  Method (_DOD, 0, NotSerialized)  // _DOD: Display Output Devices
  {
  If (CondRefOf (IDAB))
  {
  IDAB ()
  }
  Else
  {
   [truncated]

Unfortunately I'm far away from understanding the ASL, so I can only  
guess this is the part where my graphics device is described. Also,  
because I don't have a PEG device with DOD / DOS, I fear the described  
patch for the X220 will not solve the problem for me?


My ASL is located here:  
https://d2ux.org/owncloud/public.php?service=filest=7022f90cea5e48da7fa65806c0d66091


I would really appreciate if someone with more ACPI background could  
take a look at it and

tell me what I should try next.

Thanks  kind regards,
Matthias


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way (and trying to apply the same fix to X121e)

2013-07-08 Thread Matthias Petermann 


Hello,

I applied the patch, trying to get brightness controls for my X121e.

But it looks like I need a different loader.conf setting.

hw.pci0.0.2.0.handle=_SB_.PCI0.PEG.VID

doesn't work. In my ASl there is only one device providing DOD / DOS:

Scope (_SB.PCI0)
 {
 Device (GFX0)
 {
 Name (_ADR, 0x0002)  // _ADR: Address
 Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output  
Switching

 {
 Store (And (Arg0, 0x07), DSEN)
 If (LEqual (And (Arg0, 0x03), Zero))
 {
 If (CondRefOf (HDOS))
 {
 HDOS ()
 }
 }
 }

 Method (_DOD, 0, NotSerialized)  // _DOD: Display Output Devices
 {
 If (CondRefOf (IDAB))
 {
 IDAB ()
 }
 Else
 {
  [truncated]

Unfortunately I'm far away from understanding the ASL, so I can only  
guess this is the part where my graphics device is described. Also,  
because I don't have a PEG device with DOD / DOS, I fear the described  
patch for the X220 will not solve the problem for me?


My ASL is located here:  
https://d2ux.org/owncloud/public.php?service=filest=7022f90cea5e48da7fa65806c0d66091


I would really appreciate if someone with more ACPI background could  
take a look at it and

tell me what I should try next.

Thanks  kind regards,
Matthias

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-06-17 Thread Ganael LAPLANCHE 
On Fri, 14 Jun 2013 16:00:11 -0700, matt wrote

 I'm glad you got this working, it makes the X220 (and probably 
 other laptops with similar issues) more usable on FreeBSD.

Sure, that's good news !
 
 I'll have to bring my X220 back up to current and start 
 looking at sleep issues next.

Great ! Do not hesitate if you need testing on this, I can help :)

Best regards,

--
Ganael LAPLANCHE ganael.laplan...@martymac.org
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac marty...@freebsd.org, http://www.FreeBSD.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-06-14 Thread John Baldwin 
On Thursday, March 07, 2013 9:13:38 pm matt wrote:
 On 02/28/13 09:09, John Baldwin wrote:
  On Thursday, February 28, 2013 8:15:46 am matt wrote:
  On 02/27/13 12:27, John Baldwin wrote:
  On Wednesday, February 27, 2013 1:35:43 pm matt wrote:
  On 02/27/13 09:00, John Baldwin wrote:
  If that is true, it's because your BIOS is lying. Do you have a URL to
  your ASL lying around already?
  Too big for pastebin :( +500k
 
  
https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing
  Here is where I find _DOD and _DOS methods:
 
   Device (PCI0)
   Device (VID)
   Name (_ADR, 0x0002)  // _ADR: Address
   Method (_DOS, 1, NotSerialized)  // _DOS: Disable 
Output Switching
   Method (_DOD, 0, NotSerialized)  // _DOD: Display 
Output Devices
   Device (PEG)
   Name (_ADR, 0x0001)  // _ADR: Address
   Device (VID)
   Name (_ADR, 0x00)  // _ADR: Address
   Method (_DOS, 1, NotSerialized)  // _DOS: Disable 
Output Switching
   Method (_DOD, 0, NotSerialized)  // _DOD: Display 
Output Devices
 
  PCI0.VID is a PCI device at pci0:0:2:0.
  PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0.
  It would have a child device at 0:0 that would be PCI0.PEG.VID.  Does 
the X220
  have a switchable GPU (e.g. it has built-in Intel graphics, but also has 
an
  Nvidia GPU or some such?).  If so, I imagine that PCI0.VID is the Intel 
graphics
  and PEG is the non-Intel.  The output of 'pciconf -lcv' would be useful 
to determine
  that.  If both PCI devices exist you shoudl have both acpi_video0 and 
acpi_video1.
  However, it may be that the acpi_video driver doesn't cope well with 
having multiple
  devices.
  Only Intel graphics, there is no option for switchable graphics.
  I initially thought that PEG was for Optimus usage, and left in the bios 
  by accident (i.e. Lenovo using a generic DSDT for many machines)
 
  Here is pciconf -lcf, truncated
  hostb0@pci0:0:0:0:class=0x06 card=0x21da17aa chip=0x01048086 
  rev=0x09 hdr=0x00
   vendor = 'Intel Corporation'
   device = '2nd Generation Core Processor Family DRAM Controller'
   class  = bridge
   subclass   = HOST-PCI
   cap 09[e0] = vendor (length 12) Intel cap 0 version 1
  vgapci0@pci0:0:2:0:class=0x03 card=0x21da17aa chip=0x01268086 
  rev=0x09 hdr=0x00
   vendor = 'Intel Corporation'
   device = '2nd Generation Core Processor Family Integrated 
  Graphics Controller'
   class  = display
   subclass   = VGA
   cap 05[90] = MSI supports 1 message enabled with 1 message
   cap 01[d0] = powerspec 2  supports D0 D3  current D0
   cap 13[a4] = PCI Advanced Features: FLR TP
  none0@pci0:0:22:0:class=0x078000 card=0x21da17aa chip=0x1c3a8086 
  rev=0x04 hdr=0x00
   vendor = 'Intel Corporation'
 
  As you can see there is no device at pci0:0:1:0. So no dev_t with for 
  acpi_video to probe or attach to.
 
  Nonetheless, only PEGs ACPI methods work, which is quite broken. This is 
  true for a large number of Lenovo devices, back to x61 (non-attaching 
  AGP adr) and probably including some other x series and t series.
 
  Unfortunately the ASL will not compile which makes fixing the DSDT an 
  exercise in fixing broken ACPI.
 
  What I find interesting is that as far as I can tell, there's no special 
  case handling for this device in Linux, yet backlight controls work out 
  of the box since about 3.0. Installing Linux as the OSI via loader.conf 
  is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows 
  2009 (/WIN7). I get correct (for platform) behavior when I call PEGs 
  _BCM... :(
 
  Is Linux getting this to work by doing it wrong, essentially?
  Yes.  I think the best way to fix this is to add a way to specify a
  hint to override the ACPI path associated with a PCI device.  Something
  like:
 
  hw.pci0.0.2.0.handle=\_SB_.PCI0.PEG.VID
 
  I think this patch should do the trick:
 
  Index: sys/dev/acpica/acpi_pci.c
  ===
  --- acpi_pci.c  (revision 247320)
  +++ acpi_pci.c  (working copy)
  @@ -264,6 +264,40 @@ acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 le
  return_ACPI_STATUS (AE_OK);
   }
   
  +static void
  +acpi_pci_override_handles(device_t dev)
  +{
  +   struct acpi_pci_devinfo *dinfo;
  +   device_t *devlist;
  +   int error, i, numdevs;
  +   char tunable_name[64], *path;
  +   ACPI_HANDLE handle;
  +
  +   error = device_get_children(dev, devlist, numdevs);
  +   if (error)
  +   return;
  +   for (i = 0; i  numdevs; i++) {
  +   dinfo = device_get_ivars(devlist[i]);
  +   snprintf(tunable_name, sizeof(tunable_name),
  +   hw.pci%d.%d.%d.%d.handle, dinfo-ap_dinfo.cfg.domain,
  +   dinfo-ap_dinfo.cfg.bus,

Re: Fixing X220 Video The Right Way

2013-06-14 Thread matt 
On 06/14/13 08:39, John Baldwin wrote:

 I got this to work by using 4 backslashes.  At that point the patch
 worked. (I recently got access to an X220.)  I get a local APIC
 error each time I adjust the brightness though (probably the BIOS
 is doing something wonky).
 


That's awesome! I've asked -CURRENT about the

I tried single quotes, double quotes, double backslash, and I meant to
try ascii escapes next :)

I'm glad you got this working, it makes the X220 (and probably other
laptops with similar issues) more usable on FreeBSD.

I'll have to bring my X220 back up to current and start looking at
sleep issues next.

Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-03-07 Thread matt 
On 02/28/13 09:09, John Baldwin wrote:
 On Thursday, February 28, 2013 8:15:46 am matt wrote:
 On 02/27/13 12:27, John Baldwin wrote:
 On Wednesday, February 27, 2013 1:35:43 pm matt wrote:
 On 02/27/13 09:00, John Baldwin wrote:
 If that is true, it's because your BIOS is lying. Do you have a URL to
 your ASL lying around already?
 Too big for pastebin :( +500k

 https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing
 Here is where I find _DOD and _DOS methods:

  Device (PCI0)
  Device (VID)
  Name (_ADR, 0x0002)  // _ADR: Address
  Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output 
 Switching
  Method (_DOD, 0, NotSerialized)  // _DOD: Display Output 
 Devices
  Device (PEG)
  Name (_ADR, 0x0001)  // _ADR: Address
  Device (VID)
  Name (_ADR, 0x00)  // _ADR: Address
  Method (_DOS, 1, NotSerialized)  // _DOS: Disable 
 Output Switching
  Method (_DOD, 0, NotSerialized)  // _DOD: Display 
 Output Devices

 PCI0.VID is a PCI device at pci0:0:2:0.
 PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0.
 It would have a child device at 0:0 that would be PCI0.PEG.VID.  Does the 
 X220
 have a switchable GPU (e.g. it has built-in Intel graphics, but also has an
 Nvidia GPU or some such?).  If so, I imagine that PCI0.VID is the Intel 
 graphics
 and PEG is the non-Intel.  The output of 'pciconf -lcv' would be useful to 
 determine
 that.  If both PCI devices exist you shoudl have both acpi_video0 and 
 acpi_video1.
 However, it may be that the acpi_video driver doesn't cope well with having 
 multiple
 devices.
 Only Intel graphics, there is no option for switchable graphics.
 I initially thought that PEG was for Optimus usage, and left in the bios 
 by accident (i.e. Lenovo using a generic DSDT for many machines)

 Here is pciconf -lcf, truncated
 hostb0@pci0:0:0:0:class=0x06 card=0x21da17aa chip=0x01048086 
 rev=0x09 hdr=0x00
  vendor = 'Intel Corporation'
  device = '2nd Generation Core Processor Family DRAM Controller'
  class  = bridge
  subclass   = HOST-PCI
  cap 09[e0] = vendor (length 12) Intel cap 0 version 1
 vgapci0@pci0:0:2:0:class=0x03 card=0x21da17aa chip=0x01268086 
 rev=0x09 hdr=0x00
  vendor = 'Intel Corporation'
  device = '2nd Generation Core Processor Family Integrated 
 Graphics Controller'
  class  = display
  subclass   = VGA
  cap 05[90] = MSI supports 1 message enabled with 1 message
  cap 01[d0] = powerspec 2  supports D0 D3  current D0
  cap 13[a4] = PCI Advanced Features: FLR TP
 none0@pci0:0:22:0:class=0x078000 card=0x21da17aa chip=0x1c3a8086 
 rev=0x04 hdr=0x00
  vendor = 'Intel Corporation'

 As you can see there is no device at pci0:0:1:0. So no dev_t with for 
 acpi_video to probe or attach to.

 Nonetheless, only PEGs ACPI methods work, which is quite broken. This is 
 true for a large number of Lenovo devices, back to x61 (non-attaching 
 AGP adr) and probably including some other x series and t series.

 Unfortunately the ASL will not compile which makes fixing the DSDT an 
 exercise in fixing broken ACPI.

 What I find interesting is that as far as I can tell, there's no special 
 case handling for this device in Linux, yet backlight controls work out 
 of the box since about 3.0. Installing Linux as the OSI via loader.conf 
 is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows 
 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs 
 _BCM... :(

 Is Linux getting this to work by doing it wrong, essentially?
 Yes.  I think the best way to fix this is to add a way to specify a
 hint to override the ACPI path associated with a PCI device.  Something
 like:

 hw.pci0.0.2.0.handle=\_SB_.PCI0.PEG.VID

 I think this patch should do the trick:

 Index: sys/dev/acpica/acpi_pci.c
 ===
 --- acpi_pci.c(revision 247320)
 +++ acpi_pci.c(working copy)
 @@ -264,6 +264,40 @@ acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 le
   return_ACPI_STATUS (AE_OK);
  }
  
 +static void
 +acpi_pci_override_handles(device_t dev)
 +{
 + struct acpi_pci_devinfo *dinfo;
 + device_t *devlist;
 + int error, i, numdevs;
 + char tunable_name[64], *path;
 + ACPI_HANDLE handle;
 +
 + error = device_get_children(dev, devlist, numdevs);
 + if (error)
 + return;
 + for (i = 0; i  numdevs; i++) {
 + dinfo = device_get_ivars(devlist[i]);
 + snprintf(tunable_name, sizeof(tunable_name),
 + hw.pci%d.%d.%d.%d.handle, dinfo-ap_dinfo.cfg.domain,
 + dinfo-ap_dinfo.cfg.bus, dinfo-ap_dinfo.cfg.slot,
 + dinfo-ap_dinfo.cfg.func);
 + path = getenv(tunable_name);
 + if (path ==

Re: Fixing X220 Video The Right Way

2013-03-01 Thread matt 
On 02/28/13 09:09, John Baldwin wrote:
 On Thursday, February 28, 2013 8:15:46 am matt wrote:
 On 02/27/13 12:27, John Baldwin wrote:
 On Wednesday, February 27, 2013 1:35:43 pm matt wrote:
 On 02/27/13 09:00, John Baldwin wrote:
 If that is true, it's because your BIOS is lying. Do you have a URL to
 your ASL lying around already?
 Too big for pastebin :( +500k

 https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing
 Here is where I find _DOD and _DOS methods:

  Device (PCI0)
  Device (VID)
  Name (_ADR, 0x0002)  // _ADR: Address
  Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output 
 Switching
  Method (_DOD, 0, NotSerialized)  // _DOD: Display Output 
 Devices
  Device (PEG)
  Name (_ADR, 0x0001)  // _ADR: Address
  Device (VID)
  Name (_ADR, 0x00)  // _ADR: Address
  Method (_DOS, 1, NotSerialized)  // _DOS: Disable 
 Output Switching
  Method (_DOD, 0, NotSerialized)  // _DOD: Display 
 Output Devices

 PCI0.VID is a PCI device at pci0:0:2:0.
 PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0.
 It would have a child device at 0:0 that would be PCI0.PEG.VID.  Does the 
 X220
 have a switchable GPU (e.g. it has built-in Intel graphics, but also has an
 Nvidia GPU or some such?).  If so, I imagine that PCI0.VID is the Intel 
 graphics
 and PEG is the non-Intel.  The output of 'pciconf -lcv' would be useful to 
 determine
 that.  If both PCI devices exist you shoudl have both acpi_video0 and 
 acpi_video1.
 However, it may be that the acpi_video driver doesn't cope well with having 
 multiple
 devices.
 Only Intel graphics, there is no option for switchable graphics.
 I initially thought that PEG was for Optimus usage, and left in the bios 
 by accident (i.e. Lenovo using a generic DSDT for many machines)

 Here is pciconf -lcf, truncated
 hostb0@pci0:0:0:0:class=0x06 card=0x21da17aa chip=0x01048086 
 rev=0x09 hdr=0x00
  vendor = 'Intel Corporation'
  device = '2nd Generation Core Processor Family DRAM Controller'
  class  = bridge
  subclass   = HOST-PCI
  cap 09[e0] = vendor (length 12) Intel cap 0 version 1
 vgapci0@pci0:0:2:0:class=0x03 card=0x21da17aa chip=0x01268086 
 rev=0x09 hdr=0x00
  vendor = 'Intel Corporation'
  device = '2nd Generation Core Processor Family Integrated 
 Graphics Controller'
  class  = display
  subclass   = VGA
  cap 05[90] = MSI supports 1 message enabled with 1 message
  cap 01[d0] = powerspec 2  supports D0 D3  current D0
  cap 13[a4] = PCI Advanced Features: FLR TP
 none0@pci0:0:22:0:class=0x078000 card=0x21da17aa chip=0x1c3a8086 
 rev=0x04 hdr=0x00
  vendor = 'Intel Corporation'

 As you can see there is no device at pci0:0:1:0. So no dev_t with for 
 acpi_video to probe or attach to.

 Nonetheless, only PEGs ACPI methods work, which is quite broken. This is 
 true for a large number of Lenovo devices, back to x61 (non-attaching 
 AGP adr) and probably including some other x series and t series.

 Unfortunately the ASL will not compile which makes fixing the DSDT an 
 exercise in fixing broken ACPI.

 What I find interesting is that as far as I can tell, there's no special 
 case handling for this device in Linux, yet backlight controls work out 
 of the box since about 3.0. Installing Linux as the OSI via loader.conf 
 is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows 
 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs 
 _BCM... :(

 Is Linux getting this to work by doing it wrong, essentially?
 Yes.  I think the best way to fix this is to add a way to specify a
 hint to override the ACPI path associated with a PCI device.  Something
 like:

 hw.pci0.0.2.0.handle=\_SB_.PCI0.PEG.VID

 I think this patch should do the trick:

 Index: sys/dev/acpica/acpi_pci.c
 ===
 --- acpi_pci.c(revision 247320)
 +++ acpi_pci.c(working copy)
 @@ -264,6 +264,40 @@ acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 le
   return_ACPI_STATUS (AE_OK);
  }
  
 +static void
 +acpi_pci_override_handles(device_t dev)
 +{
 + struct acpi_pci_devinfo *dinfo;
 + device_t *devlist;
 + int error, i, numdevs;
 + char tunable_name[64], *path;
 + ACPI_HANDLE handle;
 +
 + error = device_get_children(dev, devlist, numdevs);
 + if (error)
 + return;
 + for (i = 0; i  numdevs; i++) {
 + dinfo = device_get_ivars(devlist[i]);
 + snprintf(tunable_name, sizeof(tunable_name),
 + hw.pci%d.%d.%d.%d.handle, dinfo-ap_dinfo.cfg.domain,
 + dinfo-ap_dinfo.cfg.bus, dinfo-ap_dinfo.cfg.slot,
 + dinfo-ap_dinfo.cfg.func);
 + path = getenv(tunable_name);
 + if (path ==

Re: Fixing X220 Video The Right Way

2013-02-28 Thread John Baldwin 
On Thursday, February 28, 2013 8:15:46 am matt wrote:
 On 02/27/13 12:27, John Baldwin wrote:
  On Wednesday, February 27, 2013 1:35:43 pm matt wrote:
  On 02/27/13 09:00, John Baldwin wrote:
  If that is true, it's because your BIOS is lying. Do you have a URL to
  your ASL lying around already?
  Too big for pastebin :( +500k
 
  https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing
  Here is where I find _DOD and _DOS methods:
 
   Device (PCI0)
   Device (VID)
   Name (_ADR, 0x0002)  // _ADR: Address
   Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output 
  Switching
   Method (_DOD, 0, NotSerialized)  // _DOD: Display Output 
  Devices
   Device (PEG)
   Name (_ADR, 0x0001)  // _ADR: Address
   Device (VID)
   Name (_ADR, 0x00)  // _ADR: Address
   Method (_DOS, 1, NotSerialized)  // _DOS: Disable 
  Output Switching
   Method (_DOD, 0, NotSerialized)  // _DOD: Display 
  Output Devices
 
  PCI0.VID is a PCI device at pci0:0:2:0.
  PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0.
  It would have a child device at 0:0 that would be PCI0.PEG.VID.  Does the 
  X220
  have a switchable GPU (e.g. it has built-in Intel graphics, but also has an
  Nvidia GPU or some such?).  If so, I imagine that PCI0.VID is the Intel 
  graphics
  and PEG is the non-Intel.  The output of 'pciconf -lcv' would be useful to 
  determine
  that.  If both PCI devices exist you shoudl have both acpi_video0 and 
  acpi_video1.
  However, it may be that the acpi_video driver doesn't cope well with having 
  multiple
  devices.
 Only Intel graphics, there is no option for switchable graphics.
 I initially thought that PEG was for Optimus usage, and left in the bios 
 by accident (i.e. Lenovo using a generic DSDT for many machines)
 
 Here is pciconf -lcf, truncated
 hostb0@pci0:0:0:0:class=0x06 card=0x21da17aa chip=0x01048086 
 rev=0x09 hdr=0x00
  vendor = 'Intel Corporation'
  device = '2nd Generation Core Processor Family DRAM Controller'
  class  = bridge
  subclass   = HOST-PCI
  cap 09[e0] = vendor (length 12) Intel cap 0 version 1
 vgapci0@pci0:0:2:0:class=0x03 card=0x21da17aa chip=0x01268086 
 rev=0x09 hdr=0x00
  vendor = 'Intel Corporation'
  device = '2nd Generation Core Processor Family Integrated 
 Graphics Controller'
  class  = display
  subclass   = VGA
  cap 05[90] = MSI supports 1 message enabled with 1 message
  cap 01[d0] = powerspec 2  supports D0 D3  current D0
  cap 13[a4] = PCI Advanced Features: FLR TP
 none0@pci0:0:22:0:class=0x078000 card=0x21da17aa chip=0x1c3a8086 
 rev=0x04 hdr=0x00
  vendor = 'Intel Corporation'
 
 As you can see there is no device at pci0:0:1:0. So no dev_t with for 
 acpi_video to probe or attach to.
 
 Nonetheless, only PEGs ACPI methods work, which is quite broken. This is 
 true for a large number of Lenovo devices, back to x61 (non-attaching 
 AGP adr) and probably including some other x series and t series.
 
 Unfortunately the ASL will not compile which makes fixing the DSDT an 
 exercise in fixing broken ACPI.
 
 What I find interesting is that as far as I can tell, there's no special 
 case handling for this device in Linux, yet backlight controls work out 
 of the box since about 3.0. Installing Linux as the OSI via loader.conf 
 is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows 
 2009 (/WIN7). I get correct (for platform) behavior when I call PEGs 
 _BCM... :(
 
 Is Linux getting this to work by doing it wrong, essentially?

Yes.  I think the best way to fix this is to add a way to specify a
hint to override the ACPI path associated with a PCI device.  Something
like:

hw.pci0.0.2.0.handle=\_SB_.PCI0.PEG.VID

I think this patch should do the trick:

Index: sys/dev/acpica/acpi_pci.c
===
--- acpi_pci.c  (revision 247320)
+++ acpi_pci.c  (working copy)
@@ -264,6 +264,40 @@ acpi_pci_save_handle(ACPI_HANDLE handle, UINT32 le
return_ACPI_STATUS (AE_OK);
 }
 
+static void
+acpi_pci_override_handles(device_t dev)
+{
+   struct acpi_pci_devinfo *dinfo;
+   device_t *devlist;
+   int error, i, numdevs;
+   char tunable_name[64], *path;
+   ACPI_HANDLE handle;
+
+   error = device_get_children(dev, devlist, numdevs);
+   if (error)
+   return;
+   for (i = 0; i  numdevs; i++) {
+   dinfo = device_get_ivars(devlist[i]);
+   snprintf(tunable_name, sizeof(tunable_name),
+   hw.pci%d.%d.%d.%d.handle, dinfo-ap_dinfo.cfg.domain,
+   dinfo-ap_dinfo.cfg.bus, dinfo-ap_dinfo.cfg.slot,
+   dinfo-ap_dinfo.cfg.func);
+   path = getenv(tunable_name);
+   if (path ==

Re: Fixing X220 Video The Right Way

2013-02-27 Thread John Baldwin 
On Tuesday, February 26, 2013 9:32:33 pm matt wrote:
 On 02/26/13 10:46, John Baldwin wrote:
  On Monday, February 25, 2013 11:20:29 pm matt wrote:
  On 02/25/13 18:33, Adrian Chadd wrote:
  [101232] acpi_video0: ACPI video extension on vgapci0
  found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head 
#0
 
  And what do I do with acpi_get_handle ?
 
 
 
 
  I threw printfs into acpi_video, not sure if that would work for both
  vgapci or not.
  I'm not sure if I wiped out my debug patches yet, I may have a patch.
  Basically the idea is to figure out which paths in the DSDT are getting
  attached to the vgapci devices.
  devinfo -v already tells you that.
 
  For example:
 
  nexus0
acpi0
  pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0
pci0
  hostb0 pnpinfo vendor=0x8086 device=0x0100 subvendor=0x8086 
  subdevice=0x2010 class=0x06 at slot=0 function=0
  pcib1 pnpinfo vendor=0x8086 device=0x0101 subvendor=0x8086 
  subdevice=0x2010 class=0x060400 at slot=1 function=0 
handle=\_SB_.PCI0.PEG1
pci1
  vgapci0 pnpinfo vendor=0x10de device=0x0605 subvendor=0x3842 
  subdevice=0xc973 class=0x03 at slot=0 function=0
 
  (My desktop doesn't have acpi_video and doesn't have an ACPI handle for 
the 
  vgapci device, but you can see how it displays the handle for other PCI 
  devices like pcib1 which are in the ACPI namespace.)
 
  It seems like we could either try to find these paths on affected
  models, or have a tunable override for acpi_video.
  Note that the Linux discussion you posted seems a bit off.  The _ADR is
  not supposed to be unique to the entire system.  For PCI devices, _ADR
  contains the PCI device (slot) and function (as slot  16 | func), and
  the domain:bus portion of the address is implied by the parent PCI bus
  device in the ACPI namespace.  Thus, the specific handle assigned by ACPI
  is for the exact PCI location of the requisite vgapci device.  If your
  BIOS lies it is hard for us to do anything useful, at least automatically.
 
  Do the other devices in your system that have _DOD or _DOS methods show
  up as unknown ACPI devices in your devinfo -v output?
 It's not in devinfo at all for me, Adrian may have a different situation.
 
 So my laptop has _SB.PCI0.PEG.VID and _SB.PCI0.VID
 Only _SB.PCI0.VID is represented in devinfo -rv.
 As far as I know, PEG is not a real device, but an abstraction,
 possibly for Optimus use.
 It makes calls to \VIGD (integrated graphics?) and \ISOP (isOptimus?)
 This is potentially the broken bios part of things.
 
 I think I have multiple ACPI devices for a single physical device, and
 pci is attaching the wrong ACPI device to the physical device in an ivar.
 acpi_video happily uses this ivar to attempt to control video brightness.
 
 I could be entirely wrong on that, all I do know is that the working
 handle doesn't get used and the useless handle does.

If that is true, it's because your BIOS is lying.  Do you have a URL to your 
ASL lying around already?

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-02-27 Thread matt 
On 02/27/13 09:00, John Baldwin wrote:
 If that is true, it's because your BIOS is lying. Do you have a URL to
 your ASL lying around already? 
Too big for pastebin :( +500k

https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing

Thanks,

Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-02-27 Thread John Baldwin 
On Wednesday, February 27, 2013 1:35:43 pm matt wrote:
 On 02/27/13 09:00, John Baldwin wrote:
  If that is true, it's because your BIOS is lying. Do you have a URL to
  your ASL lying around already? 
 Too big for pastebin :( +500k
 
 https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing

Here is where I find _DOD and _DOS methods:

Device (PCI0)
Device (VID)
Name (_ADR, 0x0002)  // _ADR: Address
Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output 
Switching
Method (_DOD, 0, NotSerialized)  // _DOD: Display Output Devices
Device (PEG)
Name (_ADR, 0x0001)  // _ADR: Address
Device (VID)
Name (_ADR, 0x00)  // _ADR: Address
Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output 
Switching
Method (_DOD, 0, NotSerialized)  // _DOD: Display Output 
Devices

PCI0.VID is a PCI device at pci0:0:2:0.
PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0.
It would have a child device at 0:0 that would be PCI0.PEG.VID.  Does the X220
have a switchable GPU (e.g. it has built-in Intel graphics, but also has an
Nvidia GPU or some such?).  If so, I imagine that PCI0.VID is the Intel graphics
and PEG is the non-Intel.  The output of 'pciconf -lcv' would be useful to 
determine
that.  If both PCI devices exist you shoudl have both acpi_video0 and 
acpi_video1.
However, it may be that the acpi_video driver doesn't cope well with having 
multiple
devices.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-02-27 Thread Adrian Chadd 
I'll email later, but I do have two PCI devices show up in pciconf
-lv; but acpi_video() only attaches to one.

I don't know why two PCI devices show up.. guess there's more digging to do.



ADrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-02-27 Thread Erich Dollansky 
Hi,

On Wed, 27 Feb 2013 15:27:36 -0500
John Baldwin j...@freebsd.org wrote:

 On Wednesday, February 27, 2013 1:35:43 pm matt wrote:
  On 02/27/13 09:00, John Baldwin wrote:
   If that is true, it's because your BIOS is lying. Do you have a
   URL to your ASL lying around already? 
  Too big for pastebin :( +500k
  
  https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing
 
 the X220 have a switchable GPU (e.g. it has built-in Intel graphics,

it has.

 but also has an Nvidia GPU or some such?).  If so, I imagine that

No, it does not.

 PCI0.VID is the Intel graphics and PEG is the non-Intel.  The output
 of 'pciconf -lcv' would be useful to determine that.  If both PCI
 devices exist you shoudl have both acpi_video0 and acpi_video1.
 However, it may be that the acpi_video driver doesn't cope well with
 having multiple devices.
 
Erich

PS

Here is the output:

hostb0@pci0:0:0:0:  class=0x06 card=0x21da17aa
chip=0x01048086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation'
device = '2nd Generation Core Processor Family DRAM Controller'
class  = bridge
subclass   = HOST-PCI
cap 09[e0] = vendor (length 12) Intel cap 0 version 1
vgapci0@pci0:0:2:0: class=0x03 card=0x21da17aa
chip=0x01268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation'
device = '2nd Generation Core Processor Family Integrated
Graphics Controller' class  = display
subclass   = VGA
cap 05[90] = MSI supports 1 message enabled with 1 message
cap 01[d0] = powerspec 2  supports D0 D3  current D0
cap 13[a4] = PCI Advanced Features: FLR TP
none0@pci0:0:22:0:  class=0x078000 card=0x21da17aa
chip=0x1c3a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation'
device = '6 Series/C200 Series Chipset Family MEI Controller'
class  = simple comms
cap 01[50] = powerspec 3  supports D0 D3  current D0
cap 05[8c] = MSI supports 1 message, 64 bit 
uart2@pci0:0:22:3:  class=0x070002 card=0x21da17aa
chip=0x1c3d8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation'
device = '6 Series/C200 Series Chipset Family KT Controller'
class  = simple comms
subclass   = UART
cap 01[c8] = powerspec 3  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit 
em0@pci0:0:25:0:class=0x02 card=0x21ce17aa chip=0x15028086
rev=0x04 hdr=0x00 vendor = 'Intel Corporation'
device = '82579LM Gigabit Network Connection'
class  = network
subclass   = ethernet
cap 01[c8] = powerspec 2  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
cap 13[e0] = PCI Advanced Features: FLR TP
ehci0@pci0:0:26:0:  class=0x0c0320 card=0x21da17aa
chip=0x1c2d8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation'
device = '6 Series/C200 Series Chipset Family USB Enhanced Host
Controller' class  = serial bus
subclass   = USB
cap 01[50] = powerspec 2  supports D0 D3  current D0
cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14
cap 13[98] = PCI Advanced Features: FLR TP
hdac0@pci0:0:27:0:  class=0x040300 card=0x21da17aa
chip=0x1c208086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation'
device = '6 Series/C200 Series Chipset Family High Definition
Audio Controller' class  = multimedia
subclass   = HDA
cap 01[50] = powerspec 2  supports D0 D3  current D0
cap 05[60] = MSI supports 1 message, 64 bit enabled with 1 message
cap 10[70] = PCI-Express 1 root endpoint max data 128(128) FLR link
x0(x0) ecap 0002[100] = VC 1 max VC1
ecap 0005[130] = Root Complex Link Declaration 1
pcib1@pci0:0:28:0:  class=0x060400 card=0x21da17aa
chip=0x1c108086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation'
device = '6 Series/C200 Series Chipset Family PCI Express Root
Port 1' class  = bridge
subclass   = PCI-PCI
cap 10[40] = PCI-Express 2 root port slot max data 128(128) link
x0(x1) speed 0.0(5.0)
cap 05[80] = MSI supports 1 message 
cap 0d[90] = PCI Bridge card=0x21da17aa
cap 01[a0] = powerspec 2  supports D0 D3  current D0
pcib2@pci0:0:28:1:  class=0x060400 card=0x21da17aa
chip=0x1c128086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation'
device = '6 Series/C200 Series Chipset Family PCI Express Root
Port 2' class  = bridge
subclass   = PCI-PCI
cap 10[40] = PCI-Express 2 root port slot max data 128(128) link
x1(x1) speed 2.5(5.0)
cap 05[80] = MSI supports 1 message 
cap 0d[90] = PCI Bridge card=0x21da17aa
cap 01[a0] = powerspec 2  supports D0 D3  current D0
pcib3@pci0:0:28:3:  class=0x060400 card=0x21da17aa
chip=0x1c168086 rev=0xb4 hdr=0x01 vendor = 'Intel Corporation'
device = '6 Series/C200 Series Chipset Family PCI Express Root
Port 4' class  = bridge
subclass   = PCI-PCI
cap 10[40] = PCI-Express 2 root port slot max data 128(128) link
x0(x1) speed 0.0(5.0)
cap 05[80] = MSI supports 1 message

Re: Fixing X220 Video The Right Way

2013-02-27 Thread matt 

On 02/27/13 12:27, John Baldwin wrote:

On Wednesday, February 27, 2013 1:35:43 pm matt wrote:

On 02/27/13 09:00, John Baldwin wrote:

If that is true, it's because your BIOS is lying. Do you have a URL to
your ASL lying around already?

Too big for pastebin :( +500k

https://docs.google.com/file/d/0B6YlMzJxarGbVnotLUdNWWNTVG8/edit?usp=sharing

Here is where I find _DOD and _DOS methods:

 Device (PCI0)
 Device (VID)
 Name (_ADR, 0x0002)  // _ADR: Address
 Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output 
Switching
 Method (_DOD, 0, NotSerialized)  // _DOD: Display Output 
Devices
 Device (PEG)
 Name (_ADR, 0x0001)  // _ADR: Address
 Device (VID)
 Name (_ADR, 0x00)  // _ADR: Address
 Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output 
Switching
 Method (_DOD, 0, NotSerialized)  // _DOD: Display Output 
Devices

PCI0.VID is a PCI device at pci0:0:2:0.
PCI0.PEG would be a PCI-PCI bridge at pci0:0:1:0.
It would have a child device at 0:0 that would be PCI0.PEG.VID.  Does the X220
have a switchable GPU (e.g. it has built-in Intel graphics, but also has an
Nvidia GPU or some such?).  If so, I imagine that PCI0.VID is the Intel graphics
and PEG is the non-Intel.  The output of 'pciconf -lcv' would be useful to 
determine
that.  If both PCI devices exist you shoudl have both acpi_video0 and 
acpi_video1.
However, it may be that the acpi_video driver doesn't cope well with having 
multiple
devices.

Only Intel graphics, there is no option for switchable graphics.
I initially thought that PEG was for Optimus usage, and left in the bios 
by accident (i.e. Lenovo using a generic DSDT for many machines)


Here is pciconf -lcf, truncated
hostb0@pci0:0:0:0:class=0x06 card=0x21da17aa chip=0x01048086 
rev=0x09 hdr=0x00

vendor = 'Intel Corporation'
device = '2nd Generation Core Processor Family DRAM Controller'
class  = bridge
subclass   = HOST-PCI
cap 09[e0] = vendor (length 12) Intel cap 0 version 1
vgapci0@pci0:0:2:0:class=0x03 card=0x21da17aa chip=0x01268086 
rev=0x09 hdr=0x00

vendor = 'Intel Corporation'
device = '2nd Generation Core Processor Family Integrated 
Graphics Controller'

class  = display
subclass   = VGA
cap 05[90] = MSI supports 1 message enabled with 1 message
cap 01[d0] = powerspec 2  supports D0 D3  current D0
cap 13[a4] = PCI Advanced Features: FLR TP
none0@pci0:0:22:0:class=0x078000 card=0x21da17aa chip=0x1c3a8086 
rev=0x04 hdr=0x00

vendor = 'Intel Corporation'

As you can see there is no device at pci0:0:1:0. So no dev_t with for 
acpi_video to probe or attach to.


Nonetheless, only PEGs ACPI methods work, which is quite broken. This is 
true for a large number of Lenovo devices, back to x61 (non-attaching 
AGP adr) and probably including some other x series and t series.


Unfortunately the ASL will not compile which makes fixing the DSDT an 
exercise in fixing broken ACPI.


What I find interesting is that as far as I can tell, there's no special 
case handling for this device in Linux, yet backlight controls work out 
of the box since about 3.0. Installing Linux as the OSI via loader.conf 
is not the issue, unfortunately, nor Windows 2006 (/WVIS) or Windows 
2009 (/WIN7). I get correct (for platform) behavior when I call PEGs 
_BCM... :(


Is Linux getting this to work by doing it wrong, essentially?

Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-02-26 Thread John Baldwin 
On Monday, February 25, 2013 11:20:29 pm matt wrote:
 On 02/25/13 18:33, Adrian Chadd wrote:
  [101232] acpi_video0: ACPI video extension on vgapci0
  found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0
 
  And what do I do with acpi_get_handle ?
 
 
 
 
 I threw printfs into acpi_video, not sure if that would work for both
 vgapci or not.
 I'm not sure if I wiped out my debug patches yet, I may have a patch.
 Basically the idea is to figure out which paths in the DSDT are getting
 attached to the vgapci devices.

devinfo -v already tells you that.

For example:

nexus0
  acpi0
pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0
  pci0
hostb0 pnpinfo vendor=0x8086 device=0x0100 subvendor=0x8086 
subdevice=0x2010 class=0x06 at slot=0 function=0
pcib1 pnpinfo vendor=0x8086 device=0x0101 subvendor=0x8086 
subdevice=0x2010 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.PEG1
  pci1
vgapci0 pnpinfo vendor=0x10de device=0x0605 subvendor=0x3842 
subdevice=0xc973 class=0x03 at slot=0 function=0

(My desktop doesn't have acpi_video and doesn't have an ACPI handle for the 
vgapci device, but you can see how it displays the handle for other PCI 
devices like pcib1 which are in the ACPI namespace.)

 It seems like we could either try to find these paths on affected
 models, or have a tunable override for acpi_video.

Note that the Linux discussion you posted seems a bit off.  The _ADR is
not supposed to be unique to the entire system.  For PCI devices, _ADR
contains the PCI device (slot) and function (as slot  16 | func), and
the domain:bus portion of the address is implied by the parent PCI bus
device in the ACPI namespace.  Thus, the specific handle assigned by ACPI
is for the exact PCI location of the requisite vgapci device.  If your
BIOS lies it is hard for us to do anything useful, at least automatically.

Do the other devices in your system that have _DOD or _DOS methods show
up as unknown ACPI devices in your devinfo -v output?

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-02-26 Thread matt 
On 02/26/13 10:46, John Baldwin wrote:
 On Monday, February 25, 2013 11:20:29 pm matt wrote:
 On 02/25/13 18:33, Adrian Chadd wrote:
 [101232] acpi_video0: ACPI video extension on vgapci0
 found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0

 And what do I do with acpi_get_handle ?




 I threw printfs into acpi_video, not sure if that would work for both
 vgapci or not.
 I'm not sure if I wiped out my debug patches yet, I may have a patch.
 Basically the idea is to figure out which paths in the DSDT are getting
 attached to the vgapci devices.
 devinfo -v already tells you that.

 For example:

 nexus0
   acpi0
 pcib0 pnpinfo _HID=PNP0A08 _UID=0 at handle=\_SB_.PCI0
   pci0
 hostb0 pnpinfo vendor=0x8086 device=0x0100 subvendor=0x8086 
 subdevice=0x2010 class=0x06 at slot=0 function=0
 pcib1 pnpinfo vendor=0x8086 device=0x0101 subvendor=0x8086 
 subdevice=0x2010 class=0x060400 at slot=1 function=0 handle=\_SB_.PCI0.PEG1
   pci1
 vgapci0 pnpinfo vendor=0x10de device=0x0605 subvendor=0x3842 
 subdevice=0xc973 class=0x03 at slot=0 function=0

 (My desktop doesn't have acpi_video and doesn't have an ACPI handle for the 
 vgapci device, but you can see how it displays the handle for other PCI 
 devices like pcib1 which are in the ACPI namespace.)

 It seems like we could either try to find these paths on affected
 models, or have a tunable override for acpi_video.
 Note that the Linux discussion you posted seems a bit off.  The _ADR is
 not supposed to be unique to the entire system.  For PCI devices, _ADR
 contains the PCI device (slot) and function (as slot  16 | func), and
 the domain:bus portion of the address is implied by the parent PCI bus
 device in the ACPI namespace.  Thus, the specific handle assigned by ACPI
 is for the exact PCI location of the requisite vgapci device.  If your
 BIOS lies it is hard for us to do anything useful, at least automatically.

 Do the other devices in your system that have _DOD or _DOS methods show
 up as unknown ACPI devices in your devinfo -v output?
It's not in devinfo at all for me, Adrian may have a different situation.

So my laptop has _SB.PCI0.PEG.VID and _SB.PCI0.VID
Only _SB.PCI0.VID is represented in devinfo -rv.
As far as I know, PEG is not a real device, but an abstraction,
possibly for Optimus use.
It makes calls to \VIGD (integrated graphics?) and \ISOP (isOptimus?)
This is potentially the broken bios part of things.

I think I have multiple ACPI devices for a single physical device, and
pci is attaching the wrong ACPI device to the physical device in an ivar.
acpi_video happily uses this ivar to attempt to control video brightness.

I could be entirely wrong on that, all I do know is that the working
handle doesn't get used and the useless handle does.

Matt



Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-02-25 Thread John Baldwin 
On Sunday, February 24, 2013 2:54:39 pm matt wrote:
 I am working on fixing acpi_video for X220.
 
 My X220 is back to FreeBSD land, and I always felt \VBRC calls were dirty.
 So I've set out to fix acpi_video to work naturally, as it does in linux
 land.
 
 Background:
 Lenovo laptops boot in a mode where the brightness keys automagically
 work, under BIOS/EC control.
 This gets blown away (for us) shortly after Kernel attach.
 
 At this point, the acpi method \NBCF will return 0, which means acpi
 cannot control video brightness.
 
 Once we touch the _BCL method on the video output (even inactive ones),
 \NBCF returns 1 and will allow acpi control.
 
 You may remember that acpi_video records some brightness value that
 changes with keypresses, but does not work on X220.
 
 Current status:
 If I modify acpi video to attach to \_SB.PCI0.PEG.VID, brightness works
 via sysctl but not keypress (\NBCF = 1)
 
 If I leave that alone, but just redirect the brightness set function to
 \_SB.PCI0.PEG.VID.LCD0._BCM, the keyboard works
 
 That is obviously a hack, but it indicates something is going on here.
 
 I think that get_acpi_handle() on the X220 vgapci is returning the wrong
 ACPI_HANDLE.
 Perhaps this is why the screen stays off when resume used to work?
 
 Obviously it can be fixed by hard coding this path into acpi_video, but
 I feel like that is definitely the wrong way.
 A tunable for an acpi_video override might be useful, but it still
 leaves potentially the wrong path in vgapci's IVARs.
 
 Is there a better place to correct the ACPI_PATH that gets stored in
 vgapci's ivar? Is there already a tunable I can use to fix this?

vgapci's ivar is set by the PCI address.  Do you have multiple vgapci devices?

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-02-25 Thread matt 
On 02/25/13 10:30, John Baldwin wrote:

 Is there a better place to correct the ACPI_PATH that gets stored in
 vgapci's ivar? Is there already a tunable I can use to fix this?
 vgapci's ivar is set by the PCI address.  Do you have multiple vgapci devices?

No, just one. I think that the DSDT is very creative on recent Lenovos
(read: broken). There are multiple video devices defined, with
functional calls that nonetheless don't work to actually do anything.
The acpi_get_handle() call in acpi_video returns a handle that has no
active outputs and doesn't have any control over the brightness. The
other path can control brightness.

Here's a related discussion on Linux, I'm not sure how much applies
other than the situation discussed:
http://comments.gmane.org/gmane.linux.acpi.devel/57228

The same thing happens on AGP thinkpads, I believe, based on Mitsuru
Iwasaki's comment a long time ago to an X220 thread.

Matt

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-02-25 Thread Adrian Chadd 
On 25 February 2013 17:53, matt sendtom...@gmail.com wrote:

 No, just one. I think that the DSDT is very creative on recent Lenovos
 (read: broken). There are multiple video devices defined, with
 functional calls that nonetheless don't work to actually do anything.
 The acpi_get_handle() call in acpi_video returns a handle that has no
 active outputs and doesn't have any control over the brightness. The
 other path can control brightness.


My T400 has:


vgapci0@pci0:0:2:0: class=0x03 card=0x20e417aa chip=0x2a428086
rev=0x07 hdr=0x00
vendor = 'Intel Corporation'
device = 'Mobile 4 Series Chipset Integrated Graphics Controller'
class  = display
subclass   = VGA
vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086
rev=0x07 hdr=0x00
vendor = 'Intel Corporation'
device = 'Mobile 4 Series Chipset Integrated Graphics Controller'
class  = display

And I get glitches in xorg on 9.1 when I have multiple windows of
different sizes.



Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-02-25 Thread matt 
On 02/25/13 18:19, Adrian Chadd wrote:

 My T400 has:


 vgapci0@pci0:0:2:0: class=0x03 card=0x20e417aa chip=0x2a428086
 rev=0x07 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Mobile 4 Series Chipset Integrated Graphics Controller'
 class  = display
 subclass   = VGA
 vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086
 rev=0x07 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Mobile 4 Series Chipset Integrated Graphics Controller'
 class  = display

 And I get glitches in xorg on 9.1 when I have multiple windows of
 different sizes.



 Adrian

Does acpi_video like either one?
Does acpi_get_handle return the same path?

Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-02-25 Thread Adrian Chadd 
[101232] acpi_video0: ACPI video extension on vgapci0
found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0

And what do I do with acpi_get_handle ?



Adrian


On 25 February 2013 18:23, matt sendtom...@gmail.com wrote:
 On 02/25/13 18:19, Adrian Chadd wrote:

 My T400 has:


 vgapci0@pci0:0:2:0: class=0x03 card=0x20e417aa chip=0x2a428086
 rev=0x07 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Mobile 4 Series Chipset Integrated Graphics Controller'
 class  = display
 subclass   = VGA
 vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086
 rev=0x07 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Mobile 4 Series Chipset Integrated Graphics Controller'
 class  = display

 And I get glitches in xorg on 9.1 when I have multiple windows of
 different sizes.



 Adrian

 Does acpi_video like either one?
 Does acpi_get_handle return the same path?

 Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fixing X220 Video The Right Way

2013-02-25 Thread matt 
On 02/25/13 18:33, Adrian Chadd wrote:
 [101232] acpi_video0: ACPI video extension on vgapci0
 found Internal/Integrated Digital Flat Panel(400), idx#0, port#0, head #0

 And what do I do with acpi_get_handle ?




I threw printfs into acpi_video, not sure if that would work for both
vgapci or not.
I'm not sure if I wiped out my debug patches yet, I may have a patch.
Basically the idea is to figure out which paths in the DSDT are getting
attached to the vgapci devices.

This dsdt patch from Mitsuru Iwasaki illustrates fixing a similar issue
to X220 via a custom dsdt
http://people.freebsd.org/~iwasaki/acpi/tpx61.asl.diff
http://people.freebsd.org/%7Eiwasaki/acpi/tpx61.asl.diff

It seems like we could either try to find these paths on affected
models, or have a tunable override for acpi_video.

Matt

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Fixing X220 Video The Right Way

2013-02-24 Thread matt 
I am working on fixing acpi_video for X220.

My X220 is back to FreeBSD land, and I always felt \VBRC calls were dirty.
So I've set out to fix acpi_video to work naturally, as it does in linux
land.

Background:
Lenovo laptops boot in a mode where the brightness keys automagically
work, under BIOS/EC control.
This gets blown away (for us) shortly after Kernel attach.

At this point, the acpi method \NBCF will return 0, which means acpi
cannot control video brightness.

Once we touch the _BCL method on the video output (even inactive ones),
\NBCF returns 1 and will allow acpi control.

You may remember that acpi_video records some brightness value that
changes with keypresses, but does not work on X220.

Current status:
If I modify acpi video to attach to \_SB.PCI0.PEG.VID, brightness works
via sysctl but not keypress (\NBCF = 1)

If I leave that alone, but just redirect the brightness set function to
\_SB.PCI0.PEG.VID.LCD0._BCM, the keyboard works

That is obviously a hack, but it indicates something is going on here.

I think that get_acpi_handle() on the X220 vgapci is returning the wrong
ACPI_HANDLE.
Perhaps this is why the screen stays off when resume used to work?

Obviously it can be fixed by hard coding this path into acpi_video, but
I feel like that is definitely the wrong way.
A tunable for an acpi_video override might be useful, but it still
leaves potentially the wrong path in vgapci's IVARs.

Is there a better place to correct the ACPI_PATH that gets stored in
vgapci's ivar? Is there already a tunable I can use to fix this?

Thanks!

Matt




___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org