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

[Ben Armstrong]

On 06/13/2010 11:19 AM, Luca Niccoli wrote:
> I've been having some hardware problems lately with my eee, so I don't
> know how much intensive work I'll be able to do with it (I'm
> experiencing some random hard freezes that make working with it a
> pain).
>    

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 ...

> I could surely do some polishing and fixing if needed though.
>    

I'd appreciate that.

> The state as of now is:
> #581312 is a blocker, wireless toggling is completely broken in
> acpi-support as of now.
>    

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.

> I can't think of a clever way of supporting wireless toggling with
> rt2870 on broken kernels; I guess depending on linux>= 2.6.32-5 would
> be by far the easiest way. The user could still be runnning an old one
> though, but it's a bug in the kernel and we can't do much about it..
>    

I agree.

> The computer doesn't suspend when the lid is closed (if a power
> manager doesn't do that on its own), since taht is the default in
> acpi-support. Some time ago it was rumored that it could be a thermal
> problem for eees, but [0] seems to suggest it is not. It would be a
> change of behaviour though.
>    

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.

> 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 same goes for OSD
>    

Yes, I've always hated our own OSD.  I don't think it's important to 
keep it, given that better solutions are available.

> 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?

> In my branch I moved scripts away from /etc. I think this is the most
> sensible choice, but Damyan disagrees. It's not something that is
> needed for the integration with acpi-support at all, but If a choice
> is made to keep scripts in /etc then you have to move scripts back
> before changing my branch
>    

I'm not comfortable with having scripts in /etc either.  People who want 
to provide their own custom scripts can still provide their own and 
change /etc/acpi/events/* to point at them.

Ben