[Debian-eeepc-devel] New version of eeepc-acpi-scripts needs testing

[Damyan Ivanov]

-=| Iván Sánchez Ortega, Sat, Sep 06, 2008 at 02:24:22AM +0200 |=-
> El Sábado, 6 de Septiembre de 2008, Damyan Ivanov escribió:
> [...]
> > Please fetch[1] the source from the Git repository, build[2],
> > install[3] and test[4] the package.
> 
> Hhhmm. Kind of breaks things if you're using 2.6.25 on a 901 (which I am). 
> Camera toggling won't work and toggling won't work 'cause the control files 
> for both devices are hard-coded (in functions.sh) to match those of a 2.6.26 
> kernel.

This is a bug. Please tell me where are the control nodes for 2.6.25 
so that the same scheme as for wlan can pe applied.

> Keep in mind that, AFAIK, the 2.6.26 eeepc_laptop kernel module will 
> create all possible control files, regardless of the control methods 

I think it was me spreading this, but it is not true. I checked, I do 
not have a bluetooth control node (901, BT enabled in the BIOS, the 
control flags end with '3'). Perhaps that "node" was created by me by 
echo > and I didn't notice the difference.

> available (I have to check the last version of the source, though).  
> That means that the OSD may display "Camera off" instead of "Camera 
> unavailable" for the 701 2G (idem for bluetooth).

Please do.

> Changing the actions related to the softbuttons does work (once I hacked the 
> control files for my devices). Cool.

Good. That was an important piece of functionality.

> Pushing softkey #1 does not "turn the lid off", but the *screen* off. Sue a 
> sleepchecker ;-)

I just confused "lid" with the part that emits "light". Thanks for the 
correction.

> Bluetooth gets borked if I plug in a BT USB dongle (additionally to the 
> built-in BT, that is). Doing a /etc/init.d/bluetooth restart seemed to fix 
> that. It can be reproduced, I don't know the right combination of 
> circumstances. I also managed to inexplicably bork half my running 
> system in the process. This will need to be looked into. Maybe I 
> just did a "rmmod hci_usb" manually when I shouldn't have to.

I'll test this this weekend, hopefully. If you beat me with patches, 
even better :)

> Suggestion: let the user configure custom commands to run on wlan off / wlan 

this is already possible as /etc/acpi/actions/wireless.sh is a 
conffile.

> on / bluetooth off / bluetooth on.

these are extendable via the hotkey configuration mechanism. Did you 
notice the lenghty comments in /etc/default/eeepc-acpi-scripts?

Anyway, I'll should be moved to separate files under 
/etc/acpi/actions/ so that customising them is easier, similarly to 
wireless.sh

> e.g. I want to run wpa_supplicant on wlan on, and I want to kill it 
> on wlan of.

This is handled by the suggested configuration from the wiki (either 
the wpa_supplicant parts, or network-manager parts)

> I want to kill eth0 if I use wlan. I want to start gpsd with 
> bluetooth and stop it accordingly (I use a BT GPS quite frequently).  
> I want to start and stop bluetooth services (/etc/init.d/bluetooth 
> start|stop) automatically.

Sure, this is all possible via the extension mechanism -- write a 
function that does what yyou want in hotkey.sh, put its name in 
SOFTBTNx_ACTION vairable in default/ or edit the corresponfing script 
under /etc/acpi/actions

> Implementation of gnome-osd seems like a cool idea, altough I prefer KDE. So, 
> knotify should be taken into account. I dunno. Thoughts?

Sure. The probme foor me adding this is that I don't use KDE, so if 
you can tell me what command to run, I'll add it.

> I miss festival/flite O:-)

I am sure I already mentioned patches are welcome :)

> Speaking of notifications: I think that the "notify" bash function should 
> receive two, not one parameter: a "type" of notification and the notification 
> text. This way, gnome-osd would be able to display a shiny icon of a speaker 
> when the volume is changed, or a icon of a webcam when the webcam is toggled. 
> I'll try to find some time to hack a prototype.

The markup used[1] by gnome-osd can't support images, but I find it a 
nice idea regardless as other notification services (knotify?) may be 
able to take advantage.

 [1] http://library.gnome.org/devel/pango/unstable/PangoMarkupFormat.html


Thank you for your extensive comments. TODO updated.

-- 
dam            JabberID: dam at jabber.minus273.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/attachments/20080906/2d6a178d/attachment.pgp