> Hi John,
Hello Bruno
> On Fri, Jul 14, 2006 at 02:05:40AM -0400, [email protected] 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@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@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.
>
>
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.