[Debian-eeepc-devel] eeepc-acpi-scripts integration: please test

[Luca Niccoli]

On 20 June 2010 15:32, Ben Armstrong <synrg at sanctuary.nslug.ns.ca> wrote:

> Sorry to hear this.  Any idea about what it might be?  Which model?  Are you
> using S.H.E.?  If so, have you tried disabling the feature?  In any event,
> this should be discussed in a separate thread ...

Actually, I'm not experiencing it anymore.
Since I only saw the problem while I was in a specific place, I think
it could have been some kind of very weird bug in the wireless drivers
and in the AP.
The hard freeze made it hard to investigate though.

> A blocker for working with Lenny kernels, but wifi toggling works for me
> with your branch and the 2.6.32 kernel now in Squeeze.  What's the problem?
>  I don't think acpi-support or eeepc-acpi-scripts is needed to make wifi
> toggling work, as the eeepc_laptop module toggles it via rfkill directly
> without any scripts.

Well, I doubt that acpi-support will ship in squeeze without at least
reverting the patch that broke wireless toggling.
If they take the patch away, than we could have the kernel and the
script both toggling wifi, with no net effect.
Moreover, the kernel just does the rfkill toggling itself, but waking
up wicd or bringing the interface up for wpa_supplicant to start
scannig again must be done in userspace.

> Hmm.  Personally I have no problem with this, but some people may.  We would
> at least need to document some workaround for people wishing to preserve
> this behaviour.

I sure think the transition will need some notes in NEWS.Debian.gz

>> The mixer stuff should probably be removed or moved to acpi-support.
>> Since in the integration branch it's turned off by default, this isn't
>> a big problem.
>>
>
> This is more of a problem.  People expect the volume keys should 'just work'
> and won't be happy if suddenly they don't.  Do you have plans to submit
> patches for acpi-support?  How are volume keys handled on other systems?  Is
> there support in acpi-support for them presently, or do we have a bunch of
> hardware-specific solutions for them, too?

The main problem with the volume stuff is that by default it is
handled by the most common DEs.
This leads to double-toggling mute for most users.
I can't think of a way to reliably detect if some program is listening
to XF86 volume keys, like we do with power managers.
acpi-support just makes sure to send a keystroke event to X. This
could be a problem too, because new kernels synthesize the same event,
so there could still be the double mute problem.
This has been masked by a bug in acpi_fakekey until now; but I just
saw it has been fixed. I still have to test and see what happens; it
could be necessary to remove the event synthesizing from acpi-support
since new kernels do that on their own.
What bugs me about the mixer stuff is that it may be useful for people
not using X, so I don't feel happy about simply saying 'it's better
done in X'.
If (and it's a big if, that is best answered by whomever did it) our
mixer implementation is flexible enough, we could try to move it in
acpi-support, turned off by default.
Then who needs it has just to change a variable in /etc/default/
Otherwise, we could keep it in eeepc-acpi-script defaulted to off.

>> The same does NOT go for vga toggle: it will do things on non-eee
>> systems, and it shouldn't. Since the functionality we are providing
>> depends on Xorg being running anyway, I think we should let some X
>> program deal with it (xfce, gnome and kde at least do that by default
>> I think)
>>
>
> We have lots of users on LXDE or just a plain WM of some kind, so I would
> not be happy to see this break for them.  What about continuing to support
> eee-specific behaviours in eeepc-acpi-scripts by checking the kind of
> hardware we're running on and disabling the feature if it is run on a
> non-eee?

I guess this can be done. I'll have a look into it.

Cheers,

Luca