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

[Danny Kukawka]

On Donnerstag, 10. Juli 2008, Matthew Garrett wrote:
> On Thu, Jul 10, 2008 at 04:10:00PM +0200, Danny Kukawka wrote:
> > 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.
>
> The problem is that we want the other functionality that the dcdbas
> module provides (killswitch support and so on) - but the correct way to
> do backlight control on machines which support it is through the ACPI
> driver, not the dcdbas mess. 

It's not such a mess, it works for me perfectly since ages.

> That's a userspace policy decision rather 
> than a kernel one, so it ought to be hal that handles that situation.
> It's also machine and configuration dependent, so keying off kernel
> versions or DMI information isn't going to work.

Then go the same way as proposed in the Macbook/apple case. Simply remove/stop 
the device/addon if you get a device which now should handle the backlight. 
The only you need is a clear way to say you have now a (working!) 
device/interface which substitute the special device/addon.

> > 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.
>
> I'm not sure this would work. What happens if
>
> 1) acpi video device exists. hal is started.

I assume you mean video is loaded but dcdbas not.

> 2) hal "stops" addon, but addon hasn't been started yet

? What should be the problem? The fdi rule try to check if there is also a 
dcdbas device and backlight interface/addon, but if there nothing is HAL 
don't need to stop the addon. 

> 3) dcdbas driver gets loaded, addon gets started.

The FDI file need's only a check if there is already a backlight interface 
which would do the same (and would work!) as the dcdbas backlight interface. 
In this case simply don't spawn the dcdbas backlight interface and if there 
isn't already an interface simply spawn the device which would start the 
addon.

> ? The only thing I've thought of is to add a property to a defined
> location if a generic backlight interface is present, and then check
> that property doesn't exist before the addon is started. Something like:
>
> <match key="info.subsystem" string="backlight">
>   <merge key="/org/freedesktop/Hal/devices/computer:backlight.generic"
> type="bool">true</merge>
> </match>

1) we have already laptop_panel.access_method=general on the backlight 
interface. You could try to match this (maybe via a new FDI directive).

2) My tip: This would not work at all because some devices (as e.g. Macbook 
backlight) get spawned directly with the computer root object (IIRC) and 
because you can't be sure that the generic device get added e.g. before the 
dcdbas device.

Danny