On 20 June 2010 15:32, Ben Armstrong <[email protected]> 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 _______________________________________________ Debian-eeepc-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel
