Date: Mon, 17 Jul 2006 14:50:20 GMT From: Bruno Ducrot <bruno@poupinou.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/100271: [acpi] [patch] acpi_video cant identify some Dell lcd's. Message-ID: <200607171450.k6HEoKAY093788@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/100271; it has been noted by GNATS. From: Bruno Ducrot <bruno@poupinou.org> To: bug-followup@FreeBSD.org, john@utzweb.net Cc: Subject: Re: kern/100271: [acpi] [patch] acpi_video cant identify some Dell lcd's. Date: Mon, 17 Jul 2006 16:40:22 +0200 Hi, Looking : http://people.freebsd.org/~hrs/acpi_video.c.diff I think this part is problematic: + display_index = adr & DOD_DEVID_MASK_DISPIDX; + display_port = (adr & DOD_DEVID_MASK_DISPPORT) >> 4; + + if (!(adr & DOD_DEVID_SCHEME_STD)) { + printf("Ignore non-standard device (%x).\n", + adr & DOD_DEVID_MASK_FULL); + return(NULL); + } + ACPI 2.0b reserve bits 30-31 to be 0, so if we follow exactly ACPI 3, that is if bit 31 is cleared then we can't be compatible with ACPI 2.0b. Therefore if we keep that if statement, we should at least verify that the DSDT is for ACPI 3. Problem is : the DSDT header do have the same revision field for both specs 2.0b and 3.0. Worst, I've seen DSDT header with revision 1, even though they contains at least ACPI 2 objects (like processors, etc.) Sato-san, do you have any thought about this issue ? -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200607171450.k6HEoKAY093788>