The Logitech HID++ 1.0 documentation actually names the fields for devices and
receiver. Clarify that and explain why enabling all of the bits is a bad idea.
Align values for easier reading the numeric values of NOTIFICATION_FLAGs. To
maintain consistency in the ordering of the values, swap keyboard_backlight with
keyboard_present.
Previously, the intent was likely to position the receiver window near the
status icon. It did so by calling move followed by present. According to the
Gtk documentation, move() may fail if the window is hidden before.
Therefore present the window *after* determining the position, but *before*
moving it. (presenting the window before getting the position gives a Gtk
warning and has unpredictable behavior wrt. the window position).
As window positioning is now enabled, add additional logic to prevent overlap
of windows: position the first window near the status icon and others on the
left. This is not idea, e.g. when the status icon is on the left side of the
screen, but the idea of positioning windows near to each other is broken anyway.
"Toggle" should mean "show or hide all windows", not "flip the visibility state
of windows". Case: one receiver window is open. When a new receiver is
connected, I also expect it to be open. Instead it is hidden, so I click the
icon. Now the new receiver window is shown, but the previous one is hidden.
Huh?! Indeed, let's fix that.
The problem is caused by starting Solaar right after installing it; while udev
does have the new rule loaded, the /dev/hidraw* device nodes already exist
with the old permissions.
Rather than doing a "udevadm --reload-rules" (which could have unknown side-
effects on other devices), instruct the user to remove and re-insert the usb
receiver. The new /dev/hidraw* device nods will be created with the right
permissions.
Generating "an unknown notification" type bailed out because of an unknown
feature type None. Since `isinstance(other, str)` is False for None, the script
will raise an exception on `isinstance(other, unicode)`.
There is no differentiation between `str` and `bytes` in Python 2, therefore
add another condition to `NamedInt.__eq__` to catch unknown types (like
`bytes`).
- `self[BATTERY_STATUS] = BATTERY_STATUS[battery_status]` should be:
`self[BATTERY_STATUS] = _hidpp20.BATTERY_STATUS[battery_status]`, otherwise
the battery status would be a single char from the string `battery-status`.
- Make `_hidpp20.BATTERY_OK` check against strings instead of a number.
- Move setting battery information to a separate function, `set_battery_info`.
This prepares for notifications when a battery error/warning occurs.
Commit 438c501fae introduced support for HID++ 1.0
battery information. That accidentally selected the third parameter instead of
the second one. This commit fixes that and additionally adds a "fully charged"
status too that was found on the K800.
The K710 keyboard is (according to the issue reporter) part of a MK710 combo
(which also contains a M705 mouse). Observing a succesful 07 register read,
I think that it is a HID++ 1.0 device too that uses the same register for FN
key swapping as K800.
Previously, only the first parameter byte can be read or written. After this
patch, it is possible to select/write more bytes by specifying a mask of type
bytes with the appropriate length.
This applies to K800 but it seems also to apply to M510. The numbers are based
on the HID++ 2.0 spec that state the following for GetBatteryCapability:
If number of levels < 10 or if mileage is disabled then report are
mapped to 4 levels this way.
0%->10% critical
11%->30% low
31%->80% good
81%->100% full
i.e. to report battery low, FW send 25%, to report battery good, FW send 50%.
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
Daniel Pavel
Peter Wu