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 _______________________________________________ Debian-eeepc-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel
