Re: pmud & pbbuttonsd confilct in sarge-testing ?
> I don't agree that pbbuttonsd should be split up into a powermanagement and an
> event part. Powermanagement is a complex thing and most of the event handling
> in pbbuttonsd will be used to reduce power consumption. Even If you split up
> the functionallity the programs need to work together like they already do
> under the cover of pbbuttonsd. Otherwise it wouldn't be possible for the
> powermanagement part for example to reduce backlight brightness or switch the
> screen off because the event handler don't know of the old brightness and
> wouldn't be able to restore the old brightness if the user use the brightness
> hotkeys. You might try to handle this with a whole bunch of shell scripts but
> I doubt that this solution would be better than pbbuttonsd.
Current screen backlight level can be read from the kernel just as easy as
it's set. You should do that anyway, just in case someone changed the
backlight level using, for example, tools like fblevel.
Anyway, I'm not suggesting you split pbbuttonsd. I'm suggesting someone
who wants things handled by independent components can still do that.
> > BTW, the 'event handling with no power management' would be nice for
> > desktop machines that can't use power management - does compatibility mode
> > fully disable powermanagement in pbbuttonsd, or do you check for pmud
> > running and take over power management anyway if no pmud is found?
>
> Compatibility mode means that all functions handled by pmud will be disabled
> in pbbuttonsd. This are mainly the cover management (close/open events) and
Unconditionally, or conditional on pmud running, is what I was asking. I
take your answer to mean 'unconditionally', which would be sufficient for
that purpose.
> suspend-to-ram. Everything else is done by pbbuttonsd. This must be paid with
> some disadvantages. For example pmud doesn't save the keyboard settings
> before triggering sleep. They are lost after wakeup and must be reset by
> external programs.Pbbuttonsd takes care of this.
Right, that's something I should look into. If this works the same as
fnset it's going to be plain horrible to get right on all sorts of
keyboards :-(
Michael
Reply to: