On 09/20/2011 03:17 PM, Cristian Rigamonti wrote: > On Tue, Sep 20, 2011 at 11:52:29AM -0300, Ben Armstrong wrote: >> >> Which version of eeepc-acpi-scripts are you using? > > The 1.1.11 package from Debian testing. > >> Did you see my earlier note in this thread, posted this morning? > > Just seen it (sorry I wasn't yet subscribed to the list); of course I can use > my > window manager settings to overcome the keys, but I was looking for a more > general solution (BTW the LCD backlight keys are currently working OK both in > X > and in the console).
The general solution *is* the window manager solution. Window managers and desktop environments should have default mappings for standard keys. Drivers should fire standard key events. ACPI scripts should not get in the middle unless they absolutely have to (and I would say what they should do in that case is map the ACPI event to fire a key with acpi_fakekey and *then* let the WM/DE handle it). If the driver doesn't fire a key at all, it's a bug on the driver. File it on the kernel and we'll forward it upstream. If the driver fires a key but the WM/DE doesn't provide a default mapping for that key (and it's a standard, non-hardware-specific key) arguably, that's a bug in the WM or DE. If the WM or DE upstream doesn't agree it's a standard key, maybe you should consider using one that does. If you find no WM or DE agrees it's a standard key, well, we'll cross that bridge when we get to it. :) Just about the only key I would agree is possibly non-standard and Eee-specific is Fn-Spacebar, the "Super Hybrid Engine" key. Ideally, if for no other reason, to be consistent, that should follow the same model. That being said, even though the ASUS implementation is a bit strange, I would say this key is a kind of "performance" hotkey that surely exists in other hardware, so eventually some standard keysym that X understands should be decided upon for it. As for what agent on the desktop would respond to and act on the (privileged) action that the S.H.E. key should trigger, that's perhaps a separate issue that should be tackled in the same manner as however you make an applet that modifies cpufreq settings on the fly, rather than some hardcoded acpi script behaviour. And finally, for those using neither a WM nor DE, yes, I do see the appeal of acpi scripts, but I still think it is cleaner to generalize the keyboard as "just a bunch of keys" that generate input events that are then handled by your front end rather than hardwiring some of them to do jobs "behind the scenes" without the front end even knowing it. I don't know how console-only users plan to handle multimedia keys in general, or if there are already agents available to take care of these matters, but since I am not one of those, it is not high up on my list of priorities to solve. > Anyway, I dug a bit into the scripts and maybe they need to be fixed to work > with newer eee models using the eeepc_wmi module; for example: > > - /etc/default/eeepc-acpi-scripts contains: > > FnF_VGATOGGLE='handle_vga_toggle' As I've stated, we want to get away from this model. > - /usr/share/acpi-support/eeepc-acpi-scripts/vga-toggle.sh contains: > > test -d /sys/bus/platform/devices/eeepc || exit 0 > # do nothing if package is removed > > But this directory doesn't exist on my system, though the package is > installed. /sys/bus/platform/devices/eeepc-wmi exists instead. Right. You'll find in git this reads: [ -d /sys/devices/platform/eeepc ] || [ -d /sys/devices/platform/eeepc-wmi ] || exit 0 i.e. it continue on so long as either eeepc-laptop or eeepc-wmi is loaded. we haven't fully finished support for eeepc-wmi. > Tests for the existence of this directory are found in other scripts of the > package (including the /etc/init.d script). > > I fixed all occurrences that I could find (replacing with: > test -d /sys/bus/platform/devices/eeepc* || exit 0 ), restarted the service > but I still can't get any results. you should have checked our code in git before starting down this road. > (I now get a warning about pciehp on service startup: > > Loading EeePC support modules...pciehp...FATAL: > Error inserting pciehp > (/lib/modules/3.0.0-1-686-pae/kernel/drivers/pci/hotplug/pciehp.ko): > Unknown symbol in module, or unknown parameter (see dmesg) ... (warning). that's a known bug, fixed in git. > > dmesg says: pciehp: Unknown parameter `pciehp_slot_with_bus' > > but maybe this is not relevant; I guess because I'm running linux 3.0 and > the > init script doesn't support it yet). > > This makes me wonder that maybe there are other parts of the package to be > updated in order to work with newer eee models using the eeepc_wmi module. > > Another example: some scripts try to use > /sys/class/backlight/eeepc/brightness but > that doesn't exist either on my system. > > Yet another one: /etc/acpi/if-asus-not-eee.sh from the "acpi-support" package > contains the same test (I also fixed this, but no results). Please check out the git code and dpkg-buildpackage -us -uc, then try the resulting package. Ben _______________________________________________ Debian-eeepc-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-eeepc-devel
