Disabling add-ons in the presence of a generic control device

[Danny Kukawka]

On Donnerstag, 10. Juli 2008, Matthew Garrett wrote:
> We currently have backlight control addons for a couple of systems
> (Apple and Dell spring to mind). Over time, these platforms are gaining
> kernel support for the backlight control - either through the vendor
> adding generic ACPI video support or through hardware specific drivers
> being written.

The addon for Dell get already only loaded and stopped if the dcdbas module 
get loaded/unloaded. If the module ever will provide a kernel (sysfs) 
interface to change the brightness (not sure if this will ever happen) you 
need only to match the kernel version with which it get change to prevent the 
addon from get started. I see no problem here.

If there will be a kernel backlight interface for e.g. Apple you can also 
match the kernel version to prevent the addon from start up. Or you can add a 
check to match the new interface for Apple (e.g. via the sysfs path or other 
properties) and remove the backlight device which contains the addon.
 
> I'm not quite clear on the cleanest way of doing this 
> with the fdi format, though. It needs to handle two cases:
>
> 1) The kernel driver is loaded before hal. The addon needs to never be
> started in this case.

You assume can't cover this case for sure. The only way would be currently 
(because of the nature of the current device handling and FDI workflow with 
e.g. the Macbook backlight addon/device) to stop the addon if you get a 
substituting device with the kernel interface.

> 2) The kernel driver is loaded after hal. The addon needs to be stopped.

Simply possible via a FDI rule to match for the new device and remove then the 
substituted device which would also stop the addon.

> Anyone have any thoughts on the best way to achieve this?

Danny