Do you really need to store state or should the driver just read state on start and save it on shutdown?
To me it sounds like something that might fit into the unfinished https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/display/display_adapter.cpp that uses ACPI to manage displays.
That’s a much broader topic I think. To put it bluntly, strictly speaking, no, no need to store the state, not in my case at least. Can’t talk for other hardware as of now. I wouldn’t know other ways to check, which is the current selected GPU, but to call \AMW0.DSTS, which is already something that could not be present, and I don’t want to simply shift the responsability from the BusManager to the DisplayAdapter, that wasn’t my point.
If you are thinking to extend the display_adapter.cpp, to act like some sort of HAL, that’s a different conversation… Then, it could be extended with vendor specific details/methods, like for example:
// Vendor-specific GPU switching definitions
typedef struct gpu_switch_methods {
const char *vendor_id; // DMI/ACPI vendor identifier
const char *get_state_method;
const char *set_state_method;
uint32 get_state_arg; // Some vendors need specific arguments
uint32 (*translate_state)(uint32 raw_state); // State translation function
} gpu_switch_methods;
// Vendor-specific method mappings
static gpu_switch_methods gpu_vendors[] = {
// ASUS EEE PC 1015PN and similar
{
.vendor_id = "ASUS",
.get_state_method = "\\AMW0.DSTS",
.set_state_method = "\\OSGS",
.get_state_arg = 0x90013,
.translate_state = asus_translate_state // 0x30001->1, 0x30002->2, etc
},
// Lenovo ThinkPads with switchable graphics
{
.vendor_id = "LENOVO",
.get_state_method = "\\_SB.PCI0.PEG.VID._DSM",
.set_state_method = "\\_SB.PCI0.PEG.VID._DSM",
.get_state_arg = 0,
.translate_state = lenovo_translate_state
},
// Dell with Optimus
{
.vendor_id = "Dell",
.get_state_method = "\\_SB.PCI0.GFX0._DSM",
.set_state_method = "\\_SB.PCI0.GFX0._DSM",
.get_state_arg = 0,
.translate_state = dell_translate_state
},
// Other vendors as needed
{ NULL, NULL, NULL, 0, NULL }
};
And build the logic around that…
Or, if you meant to create some sort of abstraction layer, and user-facing component(s) which would then communicate with the adapter via ioctl(), that’s again another topic.
I might see your point, or not… In any case, the reason I thought about a separate kernel driver and a program is two folded. One, because the current acpi_call utility from haiku_extras is something I cannot use, because I simply wasn’t able to figure out how (either is broken, or is not meant to be used as I thought), and don’t know how to build around that. And two, because having a separate installable package (maybe even a GUI app around it?!), would be simpler to implement from scratch, and extended for other combination of hardware (purposefully for GPU selection for next boot), than adding it to the existing “infrastructure” (at least from my perspective). It might not be a popular choice, but I think will go that route, if no better solution comes to mind.
Started this topic, because I thought it is something “fixable”, in some driver, or some other ways… Little did I know, what this topic will become…
Edit: reason: typos
I just think ACPI display management should be kept there. On init you would check if this “vendor” function exists and call it to get the value. On uninit if a value was set, call other method.