I have access to a convertible Toshiba machine where the 2nd battery is in detachable keyboard. This is the decompiled DSDT: https://hadess.fedorapeople.org/toshiba.dsl There's no BAT0, BAT1 is in the screen, and BAT2 is in the keyboard. BAT2 can be ejected (it has an _EJD method), but the dock code doesn't see it as having a battery: $ pwd /sys/devices/platform/dock.0 $ cat flags 16 $ cat type dock_station I'd eventually like to be able to say that, if I can detect that the battery is inside the dock, to mark it as such in the UI[1] (even better would be to say it's "in the keyboard" but I'm not sure we can easily detect that). [1]: https://bugzilla.gnome.org/show_bug.cgi?id=748592
(In reply to Bastien Nocera from comment #0) > I have access to a convertible Toshiba machine where the 2nd battery > is in detachable keyboard. This is the decompiled DSDT: > https://hadess.fedorapeople.org/toshiba.dsl > > There's no BAT0, BAT1 is in the screen, and BAT2 is in the keyboard. > > BAT2 can be ejected (it has an _EJD method), but the dock code doesn't > see it as having a battery: > $ pwd > /sys/devices/platform/dock.0 > $ cat flags > 16 > $ cat type > dock_station The kernel creates a dock station when it sees the following three types of ACPI device node: 1 ACPI device node that has _DCK control method, as the DOCK device node in your dsdt table and is represented as dock.0 above; 2 Battery, when it has a _EJ0 control method; 3 ATA, when it has a _EJ0 control method. The 4-8 bits of the flag is used to represent such information, but not that if it contains some devices in it. > > I'd eventually like to be able to say that, if I can detect that the > battery is inside the dock, to mark it as such in the UI[1] (even It should be easy to get such information by checking if a device node has the _EJD control method in the kernel but would require a way to pass such information to user space.
(In reply to Aaron Lu from comment #1) > (In reply to Bastien Nocera from comment #0) > > I have access to a convertible Toshiba machine where the 2nd battery > > is in detachable keyboard. This is the decompiled DSDT: > > https://hadess.fedorapeople.org/toshiba.dsl > > > > There's no BAT0, BAT1 is in the screen, and BAT2 is in the keyboard. > > > > BAT2 can be ejected (it has an _EJD method), but the dock code doesn't > > see it as having a battery: > > $ pwd > > /sys/devices/platform/dock.0 > > $ cat flags > > 16 > > $ cat type > > dock_station > > The kernel creates a dock station when it sees the following three types of > ACPI device node: > 1 ACPI device node that has _DCK control method, as the DOCK device node in > your dsdt table and is represented as dock.0 above; > 2 Battery, when it has a _EJ0 control method; > 3 ATA, when it has a _EJ0 control method. > > The 4-8 bits of the flag is used to represent such information, but not that > if it contains some devices in it. Right. But why don't the flags get set to mention "DOCK_IS_BAT" when it has the _EJD method? The device: Device (BAT2) { Name (_HID, EisaId ("PNP0C0A") /* Control Method Battery */) // _HID: Hardware ID Name (_UID, 0x02) // _UID: Unique ID Name (_PCL, Package (0x01) // _PCL: Power Consumer List matches the requirement for acpi_device_is_battery() returning TRUE: bool acpi_device_is_battery(struct acpi_device *adev) { struct acpi_hardware_id *hwid; list_for_each_entry(hwid, &adev->pnp.ids, list) if (!strcmp("PNP0C0A", hwid->id)) return true;
Are you suggesting set the DOCK_IS_BAT flag of the dock.0 device? That would mean the dock.0 device is a battery itself, which is not the case here.
But the fact that the battery is on a dock suggests that this battery is ejectable and the kernel currently lacks a way to pass such information to user space.
Where is it documented?
Documented here means I have explained the situation, i.e. in comment #3. Is there something more you need?
(In reply to Aaron Lu from comment #6) > Documented here means I have explained the situation, i.e. in comment #3. Is > there something more you need? Well, it doesn't fix my problem, which is to detect that the battery is inside the "dock" from user-space.
(In reply to Bastien Nocera from comment #7) > (In reply to Aaron Lu from comment #6) > > Documented here means I have explained the situation, i.e. in comment #3. > Is > > there something more you need? > > Well, it doesn't fix my problem, which is to detect that the battery is > inside the "dock" from user-space. I'll need to think about how to solve this(previously I thought this is a feature request and we do not deal with feature request in kernel bugzilla, but now I agree that the current code doesn't handle the BAT2 properly).
The information is apparently exported in DMI for some machines, but, in user-space, we don't have enough visibility to match those devices. See https://bugs.freedesktop.org/show_bug.cgi?id=89400 From a Lenovo x240: =============================== dmidecode ==================== Handle 0x0023, DMI type 22, 26 bytes Portable Battery Location: Front Manufacturer: SONY Name: 45N1111 Design Capacity: 23200 mWh Design Voltage: 11100 mV SBDS Version: 03.01 Maximum Error: Unknown SBDS Serial Number: 0843 SBDS Manufacture Date: 2013-02-05 SBDS Chemistry: LiP OEM-specific Information: 0x00000000 Handle 0x0024, DMI type 22, 26 bytes Portable Battery Location: Rear Manufacturer: SANYO Name: 45N1737 Design Capacity: 71280 mWh Design Voltage: 10800 mV SBDS Version: 03.01 Maximum Error: Unknown SBDS Serial Number: 682B SBDS Manufacture Date: 2013-10-23 SBDS Chemistry: LION OEM-specific Information: 0x00000000
(In reply to Bastien Nocera from comment #9) > The information is apparently exported in DMI for some machines, but, in > user-space, we don't have enough visibility to match those devices. Do you mean to match /sys/class/power_supply/BATx with the below "Portable Battery"? I saw they both have the serial number, do they match? > > See https://bugs.freedesktop.org/show_bug.cgi?id=89400 > > From a Lenovo x240: > =============================== dmidecode ==================== > Handle 0x0023, DMI type 22, 26 bytes > Portable Battery > Location: Front > Manufacturer: SONY > Name: 45N1111 > Design Capacity: 23200 mWh > Design Voltage: 11100 mV > SBDS Version: 03.01 > Maximum Error: Unknown > SBDS Serial Number: 0843 > SBDS Manufacture Date: 2013-02-05 > SBDS Chemistry: LiP > OEM-specific Information: 0x00000000 > > Handle 0x0024, DMI type 22, 26 bytes > Portable Battery > Location: Rear > Manufacturer: SANYO > Name: 45N1737 > Design Capacity: 71280 mWh > Design Voltage: 10800 mV > SBDS Version: 03.01 > Maximum Error: Unknown > SBDS Serial Number: 682B > SBDS Manufacture Date: 2013-10-23 > SBDS Chemistry: LION > OEM-specific Information: 0x00000000
(In reply to Aaron Lu from comment #10) > (In reply to Bastien Nocera from comment #9) > > The information is apparently exported in DMI for some machines, but, in > > user-space, we don't have enough visibility to match those devices. > > Do you mean to match /sys/class/power_supply/BATx with the below "Portable > Battery"? I saw they both have the serial number, do they match? They do, but we can't run dmidecode in user-space, that data needs to be exported from the kernel, and it would be best if all the battery metadata was in one place...
It seems DMI is exported to user space at: /sys/firmware/dmi/tables/DMI
ping...
(In reply to Aaron Lu from comment #12) > It seems DMI is exported to user space at: /sys/firmware/dmi/tables/DMI Which is also only readable by root, and needs to be processed by whatever application will take the decision. This information should be attached to the battery sysfs attributes themselves.
This should be a feature request I guess? i.e. the previous kernel doesn't support his functionality either. Bastien, can you please confirm? If it is a feature request, I think you should send the request to the mailing list.
Bug closed as this is a feature gap instead of bug.