ch to fix this Re: Dell/acpi_video hw.acpi.video.out0 is
probably a bug, and an important one. Re: Dell laptops
john at utzweb.net
john at utzweb.net
Sun Jul 16 01:01:19 UTC 2006
> Hi John,
Hello Bruno
> On Fri, Jul 14, 2006 at 02:05:40AM -0400, john at utzweb.net wrote:
>> 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
>
> Youre somewhat right, but your patch is wrong.
Thankyou for taking interest and reviewing my analysis and patch.
I would beg to differ with your assertions concerning the patch's
correctness, because the operation you mention below is handled a few
lines above the patch.
> Actually you have to check if ((adr & 0x0400) == 0x0400).
the & occurs at the top of the switch, here's the destroy case:
static void
acpi_video_vo_destroy(struct acpi_video_output *vo)
{
struct acpi_video_output_queue *voqh;
ACPI_SERIAL_ASSERT(video);
if (vo->vo_sysctl_tree != NULL) {
vo->vo_sysctl_tree = NULL;
sysctl_ctx_free(&vo->vo_sysctl_ctx);
}
if (vo->vo_levels != NULL)
AcpiOsFree(vo->vo_levels);
switch (vo->adr & DOD_DEVID_MASK) {
case DOD_DEVID_MONITOR:
voqh = &crt_units;
break;
case DOD_DEVID_PANEL:
case 0x400:
voqh = &lcd_units;
break;
case DOD_DEVID_TV:
voqh = &tv_units;
break;
default:
voqh = &other_units;
}
STAILQ_REMOVE(voqh, vo, acpi_video_output, vo_unit.next);
free(vo, M_ACPIVIDEO);
}
there is also the indisputable fact that it worked:
[spaz at minime /usr/home/spaz]$ sysctl hw.acpi.video
hw.acpi.video.crt0.active: 0
hw.acpi.video.lcd0.active: 1 <-- used to be out0
[spaz at minime /usr/home/spaz]$
> In fact, acpi_video.c is
> correct for ACPI spec2, but ACPI spec3 have changed in that regard, and
> only the value 0x110 (LCD internal panel) should be kept for
> backward compatility.
>
> Please look at the two specifications (v2.0c and v3) at the ACPI
> info website: http://www.acpi.info for more.
ah, the spec. thankyou!
i will take the time to read it carefully.
currently, i think that the next areas of despair with my dell are the
following:
from dmesg on boot:
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
ACPI: Found matching pin for 0.31.INTA at func 1: 255
ACPI: Found matching pin for 0.31.INTB at func 5: 11
pci_link1: BIOS IRQ 11 for 0.31.INTB is invalid
from dmesg post quitting xorg:
"Interrupt storm detected on irq 11; throttling interrupt source"
i would think that if i could figure out how to fix the invalid INTB, i'd
probably not get the interrupt storm
> (pseudo patch snipped)
>
> Cheers,
>
> --
> Bruno Ducrot
>
> -- Which is worse: ignorance or apathy?
> -- Don't know. Don't care.
>
>
More information about the freebsd-mobile
mailing list