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