Date: Fri, 14 Jul 2006 02:05:40 -0400 (EDT) From: john@utzweb.net To: john@utzweb.net Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Patch to fix this Re: Dell/acpi_video hw.acpi.video.out0 is probably a bug, and an important one. Re: Dell laptops Message-ID: <39062.69.93.78.27.1152857140.squirrel@69.93.78.27> In-Reply-To: <34247.69.93.78.27.1152835592.squirrel@69.93.78.27> References: <20060711.104708.1159134898.imp@bsdimp.com> <200607111338.01412.mistry.7@osu.edu> <Pine.GSO.4.64.0607112352430.27869@sea.ntplx.net> <200607122136.54293.mistry.7@osu.edu> <Pine.GSO.4.64.0607130824240.6165@sea.ntplx.net> <44B6401F.8050507@centtech.com> <Pine.GSO.4.64.0607130848190.6165@sea.ntplx.net> <44B641F2.2020500@centtech.com> <Pine.GSO.4.64.0607130900460.6165@sea.ntplx.net> <32884.69.93.78.27.1152831695.squirrel@69.93.78.27> <34247.69.93.78.27.1152835592.squirrel@69.93.78.27>
next in thread | previous in thread | raw e-mail | index | archive | help
acpi_video.c expects the lcd to be identified as 0x0110, but my Dell
Latitude C400 (and probably others) id's the lcd at 0x0400:
Device (LCD)
{
Method (_ADR, 0, NotSerialized)
{
Return (0x0400)
}
so, acpi_video needs to account for this.
got this sorted, and now the display turns back on, here's the patch, i
already send-pr'd it
spaz@minime /usr/home/spaz]$ diff -u acpi_videoorig.c acpi_video.c
--- acpi_videoorig.c Thu Jul 13 22:44:40 2006
+++ acpi_video.c Thu Jul 13 22:44:28 2006
@@ -113,6 +113,7 @@
#define DOD_DEVID_MONITOR 0x0100
#define DOD_DEVID_PANEL 0x0110
#define DOD_DEVID_TV 0x0200
+#define DOD_DEVID_LCD 0x0400
#define DOD_BIOS (1 << 16)
#define DOD_NONVGA (1 << 17)
#define DOD_HEAD_ID_SHIFT 18
@@ -416,6 +417,7 @@
voqh = &crt_units;
break;
case DOD_DEVID_PANEL:
+ case DOD_DEVID_LCD:
desc = "LCD panel";
type = "lcd";
voqh = &lcd_units;
@@ -558,6 +560,7 @@
voqh = &crt_units;
break;
case DOD_DEVID_PANEL:
+ case DOD_DEVID_LCD:
voqh = &lcd_units;
break;
case DOD_DEVID_TV:
[spaz@minime /usr/home/spaz]$
> Self Reply, i am moving this over to freebsd-acpi with this additional set
> of facts....
>
>> Hijacking this a bit, but it's very relevant IMHO
>>
>>> On Thu, 13 Jul 2006, Eric Anderson wrote:
>>>
>>>> On 07/13/06 07:50, Daniel Eischen wrote:
>>>>> On Thu, 13 Jul 2006, Eric Anderson wrote:
>>>>>
>>>>>> And then if you do:
>>>>>>
>>>>>> sysctl hw.acpi.video.out0.active=1
>>>>>> and then
>>>>>> sysctl hw.acpi.video.out0.active=0
>>>>>>
>>>>>> Does your screen do something?
>>>>>
>>>>> Yes, hw.acpi.video.out0.active=1 seems to switch to the CRT,
>>>>> but once there, setting it back to 0 does not bring it back.
>>>>> Fn + CRT/LCD also has no effect. The only way to get it back
>>>>> is to reboot.
>>>>>
>>>>
>>>> Did you try to do this too:
>>>>
>>>> sysctl hw.acpi.video.out1.active=1
>>>>
>>>> Or some other combinations?
>>>>
>>>> Sounds like it works ok, you just need to figure out which outputs map
>>>> to
>>>> your LCD/CRT/etc.
>>
>> So, if you look at:
>>
>> /usr/src/sys/dev/acpicaacpi_video.c::acpi_video_vo_init()
>>
>> you will notice that 'out' is what you get when you fall out of the
>> switch:
>>
>> switch (adr & DOD_DEVID_MASK) {
>> case DOD_DEVID_MONITOR:
>> desc = "CRT monitor";
>> type = "crt";
>> voqh = &crt_units;
>> break;
>> case DOD_DEVID_PANEL:
>> desc = "LCD panel";
>> type = "lcd";
>> voqh = &lcd_units;
>> break;
>> case DOD_DEVID_TV:
>> desc = "TV";
>> type = "tv";
>> voqh = &tv_units;
>> break;
>> default:
>> desc = "unknown output";
>> type = "out";
>> voqh = &other_units;
>> }
>>
>>
>> my Latitude C400 (i830M) also shows up with out0 and i am highly
>> confident
>> that what *should* be happening is that it should be *winning* at lcd.
>>
>> when i was running 6.1-RELEASE i tried h3xoring the switch to have the
>> lcd
>> be the default case but that didnt seem to help anything and i have not
>> tried the selfsame hack since switching over to CURRENT ( for the first
>> time since i started using FreeBSD back in 10/93!).
>>
>> the switch is quite simple, so it really looks like there are only two
>> things that could be wrong:
>>
>> 1. either the addr passed as the inparm (UNIT32 adr) is wrong
>>
>> 2. the bit's at the address are screwed up so that the dont make the
>> mask.
>>
>>
>> my devguy gut votes for 2, but i have yet to debug...urmm printf this
>> thing again.
>>
>> so who the hell is acpi_video asking?
>>
>> anybody know? i am resisting an impolite cross-post to freebsd-acpi
>> based
>> on the assumption that anybody who knows anything over there is probably
>> on this list too.
>>
>> i suspect that untwisting this will probably break the logjam on several
>> dell acpi annoyances.
>>
>> X obviously get's it right, where is the fork in the road between X and
>> ACPI?
>>
>> i *will* figure this out, but if anybody has any thoughts they wanted to
>> chime in with, i would love to read them!
>
> further facts,does this VID entry look reasonable?
>
>
> Device (VID)
> {
> Name (_ADR, 0x00020000)
> Method (_DOS, 1, NotSerialized)
> {
> Store (Arg0, MIS4)
> SMI (0x9E, MIS4)
> }
>
> Method (_DOD, 0, NotSerialized)
> {
> Return (Package (0x02)
> {
> 0x00010100,
> 0x00010400
> })
> }
>
> Device (CRT)
> {
> Method (_ADR, 0, NotSerialized)
> {
> Return (0x0100)
> }
>
> Method (_DCS, 0, NotSerialized)
> {
> Store (SMI (0x8E, 0x01), Local0)
> Return (Local0)
> }
>
> Method (_DGS, 0, NotSerialized)
> {
> Store (SMI (0x99, 0x01), Local0)
> Return (Local0)
> }
>
> Method (_DSS, 1, NotSerialized)
> {
> DSS (0x01, Arg0)
> }
> }
>
> Device (LCD)
> {
> Method (_ADR, 0, NotSerialized)
> {
> Return (0x0400)
> }
>
> Method (_DCS, 0, NotSerialized)
> {
> Store (SMI (0x8E, 0x02), Local0)
> Return (Local0)
> }
>
> Method (_DGS, 0, NotSerialized)
> {
> Store (SMI (0x99, 0x02), Local0)
> Return (Local0)
> }
>
> Method (_DSS, 1, NotSerialized)
> {
> DSS (0x02, Arg0)
> }
> }
> }
>
> what is also worthy of note is this empty VID2 entry:
>
>
> Device (VID2)
> {
> Name (_ADR, 0x00020001)
> Method (_DOS, 1, NotSerialized)
> {
> }
>
> Method (_DOD, 0, NotSerialized)
> {
> Return (Package (0x00) {})
> }
> }
>
> evidently, our ACPI code believes this to be bogus (correctly, i think),
> because the dmesg shows a complaint:
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> pci_link1: BIOS IRQ 11 for 0.31.INTB is invalid
> pci0: <ACPI PCI bus> on pcib0
> vgapci0: <VGA-compatible display> mem
> 0xe0000000-0xe7ffffff,0xf4f80000-0xf4ffffff irq 11 at device 2.0 on pci0
> agp0: <Intel 82830M (830M GMCH) SVGA controller> on vgapci0
> agp0: detected 892k stolen memory
> agp0: aperture size is 128M
> acpi_video0: <ACPI video extension> on vgapci0
> drm0: <Intel i830M GMCH> on vgapci0
> info: [drm] AGP at 0xe0000000 128MB
> info: [drm] Initialized i915 1.4.0 20060119
> vgapci1: <VGA-compatible display> mem
> 0xd8000000-0xdfffffff,0xf4f00000-0xf4f7ffff at device 2.1 on pci0
> acpi_video1: <ACPI video extension> on vgapci1
>
> evaluation of \\_SB_.PCI0.VID2._DOD makes no sense <--- WARNING HERE
>
>
> drm1: <Intel i830M GMCH> on vgapci1
> info: [drm] AGP at 0xe0000000 128MB
> info: [drm] Initialized i915 1.4.0 20060119
>
>
> does this jog anybody's cranium? what does the VID stuff look like on
> laptops where the video portion of sus/res actually works?
>
>> tnx!
>>
>> johnu
>>
>> _______________________________________________
>> freebsd-mobile@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
>> To unsubscribe, send any mail to
>> "freebsd-mobile-unsubscribe@freebsd.org"
>>
>>
>
>
> _______________________________________________
> freebsd-mobile@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "freebsd-mobile-unsubscribe@freebsd.org"
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39062.69.93.78.27.1152857140.squirrel>