Re: acpivga(4) v. MI display controls

[Jukka Ruohonen <jruohonen%iki.fi@localhost>]

On Thu, Oct 14, 2010 at 06:50:30PM -0500, David Young wrote:
> Rather than attaching new nodes at acpi0, the system should let ACPI
> BIOS inform the autoconfiguration process, which should attach one or
> more instances of a new, MI device, display(4).  For example:
> 
> vga0 at pci0 device ... function ...
> display0 at vga0: Ext. Monitor, head 0, bios detect (ACPI CRT1)
> display1 at vga0: TV, head 0, bios detect (ACPI DTV1)
> display2 at vga0: Unknown Output Device, head 0, bios detect (ACPI LCD)
>
> In this way, no single device has two representations in the device tree
> (think about the consequences, they're not pretty), and every device
> appears in the most appropriate place in the device tree for the purpose
> of suspending, resuming, detaching and re-attaching it.

This was discussed during the development process. Sure, the above is the
ideal case. Yet once again I need to remind that we can not hold back
important acpi(4) work because the perfect abstraction has not arrived, and
no one seems to really know how it should be done.

The task is not trivial. On modern x86, practically *everything* that
attachs has an ACPI counterpart. In a way we are thinking this backwards:
the attachment should perhaps be done via ACPI that has information about
the "natural" device tree (I recommend to boot with ACPIVERBOSE option and
observe the output). This is how it is supposedly done in Windows. And
consequently, *most* (MI) drivers that work on x86 need to eventually call
(MD) ACPI callbacks, and vice versa. Bringing this all together in a clean
(MI) implementation is hard and requires substantial changes, to say the
least.

- Jukka.