Apple Magic TrackPad battery level

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,
I've been following some of the discussions about
battery level stuff on bluetooth devices. As
recently I bought a bt device with this capability
and I also have an apple keyboard that can
do this too.

Most people I talked believed the device itself
send events with the battery status, and after
some investigation I found how to probe the
device. But I have a problem (of cours), running
hcidump it shows that my request is the same
as Mac OSX does it sends a GetFeature(report_id)
* I runned PacketLogger.app to be sure it worked the way HID spec says so.
which turns in 0x43 0x47 (0x47 being the report id),
but the call does not return the value, so I wonder
that maybe some code in hid-core or usbhid-core
is filtering the data somehow, or maybe I even found
a bug on the hidraw stuff.

My code added to hid-magicmouse.c into the probe function:
    __u8 *buf;
    unsigned char report_number = 0x47;

    buf = kmalloc(3 * sizeof(__u8), GFP_KERNEL);
    if (!buf) {
        ret = -ENOMEM;
        goto err_stop_hw;
    }

    memset(buf, 0, sizeof(buf));

    ret = hdev->hid_get_raw_report(hdev, report_number, buf,
sizeof(buf), HID_FEATURE_REPORT);
    if (ret != -EIO && ret != sizeof(report_number)) {
        hid_err(hdev, "unable to request BATTERY feature data (%d)\n", ret);
        goto err_stop_hw;
    }
    dbg_hid("PROBING BATTERY (%d), (%s), (%d)\n", buf[0], buf, buf[1]);


----- It produces the following on the hcidump which is what I need, but the buf
only contains the 0x43 value (which is espected as the report number
is stored there);

< ACL data: handle 11 flags 0x02 dlen 6
    L2CAP(d): cid 0x0042 len 2 [psm 17]
      HIDP: Get report: Feature report
      47
> ACL data: handle 11 flags 0x02 dlen 7
    L2CAP(d): cid 0x0040 len 3 [psm 17]
      HIDP: Data: Feature report
      47 44

As you can see my battery at the report 47 is 44 (68%), also the
hcidump show some random stuff
before the get and response but I guess it might be part of the protocol.

Any hints on how do I get the data that the device is actually sending now?

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux