Better design a simple API exposing what's necessary (just like RandR exposes mode-settings).
A DBUS interface would be perfect, and let the various local solution tap into it (like KDE's Kscreen and battery widget, etc.)
Even if it was all done inside the same company 3DFx had a similar approach for their windows drivers:
- the low-level driver, when installed by it's .INF uploads a bunch of info into the registry.
- the end-user configuration software, reads the registry and draws drop-down menus and horizontal bars to let the user change settings. These graphical edits will change variables as defined in the registry by the low-level installer.
So if you want to hack the drivers to create new settings or new mode sets, just edit the .INF file so it creates new entries in the registry, and the conf application will automagically show you newest creation.