Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple receivers #50

Closed
ivotron opened this issue May 19, 2013 · 8 comments
Closed

Support multiple receivers #50

ivotron opened this issue May 19, 2013 · 8 comments
Labels

Comments

@ivotron
Copy link

ivotron commented May 19, 2013

Wondering if it's possible to find a way to pair a device with multiple receivers.

@pwr
Copy link
Collaborator

pwr commented May 19, 2013

I'm afraid not.

From my understanding, this is a limitation of the way the receivers work, not something that can be fixed in software. Even Logitech's Windows software does not support this.

Reference: http://forums.logitech.com/t5/Keyboards-and-Keyboard-Mice/Unifying-with-multiple-recievers/td-p/529596

@pwr pwr closed this as completed May 19, 2013
@ivotron
Copy link
Author

ivotron commented May 19, 2013

It seems that an encryption key is exchanged from the receiver to the device so that it only talks to that receiver and not to any other. I wonder if there's a way of obtaining the key from the driver and share it to another receiver so that can be paired with it as well. My personal workflow doesn't involve any scenario where both receivers are active (either one or the other)

@pwr
Copy link
Collaborator

pwr commented May 19, 2013

I doubt such functionality (reading/writing the pairing key) would be exposed, maybe as a diagnostic/debugging aid for the receiver, using internal Logitech tools.
Even if it were exposed, it would be prohibitively difficult (and possibly expensive, in terms of bricked receivers) to find it by trial and error.
So unless Logitech's official public documentation -- when/if it will be made available -- will describe such functionality, it's unlikely for it to ever be available to end-users.

@ivotron
Copy link
Author

ivotron commented May 19, 2013

I see, thanks a lot!

@Lekensteyn
Copy link
Member

While this is technically not possible because of the limitation mentioned by @pwr, you could set up a udev rule that calls the pairing program with a short timeout. Solaar has a CLI, but I prefer to use the ltunify for that.

For example, when I currently want to swap a keyboard between a laptop and computer, I ssh into the the desktop, run ltunify pair. It then wait for pairing to complete (30 seconds), so I fire ltunify unpair keyboard on my laptop. Then I turn the keyboard off and on and voila, it is paired with the desktop.

I mentioned udev before, but you can also make it a cron that runs on @reboot or a PM resume hook. You then run ltunify pair 5 (or the solaar-cli equivalent) which gives you five seconds to turn your Logitech device off/on. This works only if the computer with the other receiver is far away or turned off.

@ivotron
Copy link
Author

ivotron commented May 21, 2013

Thanks @Lekensteyn, my 2nd device is an android tablet (tf101) so I can't use your method right away. It might work though, I would need to check if the python-pyudev / python3-pyudev dependencies and available python versions work OK. If I have time later I'll check.

@pwr
Copy link
Collaborator

pwr commented May 21, 2013

Technically you don't need ltunify or solaar just for the pairing. Assuming you have a /dev/hidrawX device node (where X is most likely 0), you can try running /bin/echo -ne '\0020\0377\0200\0262\0001\0000\0036' > /dev/hidraw0 in the Android shell. This should write the right bytes to the device, starting the pairing process.

However, there are some important caveats here:

  • Make sure you've found the right hidraw device. There may also be other devices on your tablet (possibly built-in) that also are handled through a hidraw device node. If you've plugged in your Logitech receiver, you should see at least one /dev/hidrawX, and one more /dev/hidrawY node for each peripheral already paired to it. Usually the first one is the receiver, and the one you need to use. If you write stuff to the wrong device, the results are unpredictable.
  • You must make sure the arguments to echo are correct. I'm not sure Android's /bin/echo supports the -n switch, and -e may or may not be necessary. To make sure, first run /bin/echo -ne '\0020\0377\0200\0262\0001\0000\0036' in the shell. You should see some garbled characters (ÿ² or something close to it), definitely not see \0020\0377\0200\0262\0001\0000\0036, and must not be a newline after the characters. If this works, you can also try the hidraw redirect.

Also, I don't have an Android device, but udev may not be available on it. In this case, you won't be able to make Solaar work anyway. Technically Solaar only uses udev for the receiver discovery (and plug-in/plug-out events), but that's a rather basic requirement for the way Solaar works as a desktop application.

@Lekensteyn
Copy link
Member

ltunify does not use udev. It makes the assumption that if the symlink target of the glob expression /sys/class/hidraw/hidraw*/device/driver matches logitech-djreceiver, then that hidraw* device is the one that must be used.

I got ltunify running on an ARM machine, the Raspberry Pi (which was not hard to do tbh). Since Android is based on Linux, it should be possible to use ltunify on the TF101.

echo works on my i9300 (CM10.1 iirc)

shell@android:/ $ type echo
echo is a shell builtin
shell@android:/ $ echo -ne '\0020\0377\0200\0262\0001\0000\0036' | hexdump -C
00000000  10 ff 80 b2 01 00 1e                              |.......|
00000007

printf should be more portable, I usually write hexadecimal representations to hidraw using:

printf '\x10\xff\x80\xb2\x01\x00\x1e' > /dev/hidraw0

The disadvantage of writing in this way is that you do not get any feedback. Note: the last 0x1e parameter is the pairing timeout in seconds. Zero means default, which is 30 seconds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants