subject:"Re\: Fixing X220 Video The Right Way"

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

when did it start working?


-adrian

On 9 August 2013 20:10, matt  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 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

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 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  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 (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=files&t=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-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-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=files&t=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=files&t=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 
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac , 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 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-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

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),
> +

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),
> +

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

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-27 Thread Erich Dollansky

Hi,

On Wed, 27 Feb 2013 15:27:36 -0500
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
> 
> 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 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 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 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 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:  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-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:  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-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:  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-25 Thread matt

On 02/25/13 18:33, Adrian Chadd wrote:
> [101232] acpi_video0:  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


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"

Re: Fixing X220 Video The Right Way

2013-02-25 Thread Adrian Chadd

[101232] acpi_video0:  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  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: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

On 25 February 2013 17:53, matt  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 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 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

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

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

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

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

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

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

Re: Fixing X220 Video The Right Way

30 matches

Site Navigation

Mail list logo

Footer information