[Debian-eeepc-devel] [SCM] Maintenance of eeepc-acpi-scripts?debian package branch, master, updated.?db56a3bc8a47819398ae7ae768722932aa9aea75
dmn at debian.org
Mon Sep 1 06:32:12 UTC 2008
-=| Iván Sánchez Ortega, Sun, Aug 31, 2008 at 10:34:23PM +0200 |=-
> El Domingo, 31 de Agosto de 2008, Damyan Ivanov escribió:
> > Iván, can you elaborate a bit?
> > Why would it return true for models without bluetooth?
> > - is it because the bluetooth control file returns 1?
> > - or, hcitool outputs something containing hci0?
> At least the 900 and the 901 have connectors for bluetooth; the 901 does have
> a bluetooth adaptor soldered to the board, whereas the 900 doesn't have
> anything soldered - see "BT_CON" here:
> In models (900) where there is nothing attached to BT_CON in the board, the
> BIOS *may* try to power up that portion on the board, and *may* return true
> even if it's powering up (in vain) an open circuit.
> I do not know the algorith used by the acpi driver, nor by the BIOS, to
> determine if there is a BT adaptor switched on. *Maybe* the board queries the
> hardware on BT_CON and is actually able to tell if there is something
> physically attached when powered on, I don't really know about this bit. I
> hope it checks for that, but today I've got my pessimist hat on.
Well, I'd rely on the laptop_eeepc driver to expose the bluetooth
control interface only if it has a chance of switching it on/off, and
return "1" only if there is evidence it is actually ON. But as this
driver does not yet support bluetooth, I am just guessing, so this
part of the code is more like the way I'd like it to be when kernel
cooperates than really used code.
Still, the check can be extended to be:
if there is a bt_control file *and* it contains "1" *and* there is a
hci0 device, then assume the internal bluetooth is ON.
From your reply I hoped you have some practical experience with the
code breaking something, though. It sounds more like a theorethical
argument to me :)
> > I also don't quite understand your suggestion. "hcitool -dev"
> > fails here complaining about unknown uption "-d".
> I mispelled the command - it's "hcitool dev | grep hci0", with no hyphen.
> "hcitool" actually looks for a bluetooth adaptor anywhere in the system. This
OK. the code falls back to exactly that when there is no bluetooth
control file in /sys (the current situation).
> method has a drawback: it would return true if I plug a external USB
> bluetooth dongle connected to my eeepc.
Indeed. Still the code may be used to turn that down :) Not exactly
more helpful that removing the dongle, but...
> > Note also that this code is used only in the handler of the fourth
> > additional key between the main keyboard and the screen. It should
> > cause no harm unless this key is pressed, requestion toggling of
> > bluetooth. Do models without bluetooth have this key? What icon does
> > it have on it?
> According to those:
> The 904HD model has this four extra keys, but no integrated bluetooth (I'm
> guessing an empty BT_CON area in the board just as the 900). I do not know
> the behaviour of the 904 about the issue.
Oh, and the eeepc-acpi-scripts would take an useful acpi key away from
Perhaps its usage should be made optional via a vairable in
/etc/default. Perhaps set on postinst (only on first installation or
when upgrading to a version supporting bluetooth) on selected models.
This would also avoid messing with usb bluetooth dongles.
> The third and fourth keys are meant to be "user-defined", and both
> have the icon of an user. Or, at least, what asus believes a user to
> be: a head and shoulders similar to the MSN messenger icon.
> With the provided Xandros installation, Fn+F2 cycles through both wlan and BT
> (see http://img208.imageshack.us/my.php?image=900wbtlv7.jpg ). I prefer
> having one of the four extra keys just for toggling BT, though. Feels *much*
> more responsive that way.
Yes, me too. What if I want to switch bluetooth on or off without
losing my wireless connection? Xandros can't do that.
> > Lastly, I did the implementation to first check whether the
> > bluetooth
> > is enabled in the control file, as when this is supported by the
> > laptop_eeepc (I know eeepc_acpi does support this, even if after an
> > additional patch), this would be the authoritative source (as for
> > wlan).
> I didn't understand this bit - which is the authoritative source for wlan -
> the control file? iwconfig? both of them, serialized?
The control file.
Thank you for your comments.
dam JabberID: dam at jabber.minus273.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/attachments/20080901/1e3ab87f/attachment.pgp
More information about the Debian-eeepc-devel