Take the 2-minute tour ×
Raspberry Pi Stack Exchange is a question and answer site for users and developers of hardware and software for Raspberry Pi. It's 100% free, no registration required.

All my other linux, windows and OSX boxes are plug and play with USB. I have a Logitech M325 mouse with a wireless USB adapter. The pi is running raspbmc. If I power-up the pi with the mouse adapter plugged in and the mouse on, all is well. If I power up the pi with the adapter plugged in and the mouse turned off, and then turn the mouse on, no mouse is detected.

Any ideas how to change this? I don't want to have to re-power the pi just because I forgot to turn the mouse on first.

raspbmc uses raspbian.

Mouse not working

  pi@raspbmc:~$ lsusb
  Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
  Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver

Mouse working

 pi@raspbmc:~$ lsusb
 Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
 Bus 001 Device 004: ID 046d:c52b Logitech, Inc. Unifying Receiver

I suspect its more to do with xbmc than with the board or os.

Mouse working:

pi@raspbmc:~$ dmesg|grep logit
logitech-djreceiver 0003:046D:C52B.0003: hiddev0: USB HID v1.11 Device [Logitech USB Receiver] on usb-bcm2708_usb-1.2/input2
logitech-djdevice 0003:046D:C52B.0004: input: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:400a] on usb-bcm2708_usb-1.2:1
pi@raspbmc:~$ ls /sys/bus/hid/drivers
hid-generic  logitech-djdevice  logitech-djreceiver

Mouse not working:

pi@raspbmc:~$ dmesg|grep logitech
logitech-djreceiver 0003:046D:C52B.0003: hiddev0: USB HID v1.11 Device [Logitech USB Receiver] on usb-bcm2708_usb-1.2/input2
logitech-djdevice 0003:046D:C52B.0004: input: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:400a] on usb-bcm2708_usb-1.2:1
pi@raspbmc:~$ ls /sys/bus/hid/drivers
hid-generic  logitech-djdevice  logitech-djreceiver

If I turn on the pi with the mouse turned off, then turn the mouse on, then unplug the USB dongle and then plug it back in again with the mouse turned on I get:

logitech-djreceiver 0003:046D:C52B.0003: hiddev0: USB HID v1.11 Device [Logitech USB Receiver] on usb-bcm2708_usb-1.2/input2
EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
Console: switching to colour dummy device 80x30
NET: Registered protocol family 10
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
input: Logitech Unifying Device. Wireless PID:400a as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2:1.2/0003:046D:C52B.0003/input/input0
logitech-djdevice 0003:046D:C52B.0004: input: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:400a] on usb-bcm2708_usb-1.2:1
usb 1-1.2: USB disconnect, device number 4
usb 1-1.2: new full-speed USB device number 5 using dwc_otg
usb 1-1.2: New USB device found, idVendor=046d, idProduct=c52b
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.2: Product: USB Receiver
usb 1-1.2: Manufacturer: Logitech
logitech-djreceiver 0003:046D:C52B.0007: hiddev0: USB HID v1.11 Device [Logitech USB Receiver] on usb-bcm2708_usb-1.2/input2
input: Logitech Unifying Device. Wireless PID:400a as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2:1.2/0003:046D:C52B.0007/input/input1
logitech-djdevice 0003:046D:C52B.0008: input: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:400a] on usb-bcm2708_usb-1.2:1

So I think linux is working fine and the mouse is being detected but XBMC is not responding to the transition from not having a pointing device to having a pointing device.

share|improve this question
    
What distro do you use? What is the output of lsusb in the two cases you described? –  Morgan Courbet Jan 7 '13 at 20:06
1  
Interestingly, if the mouse is working, and I turn the mouse off and then reboot without power cycling, and then turn the mouse on, the mouse still works. So maybe it is hardware. –  Julian Jan 7 '13 at 20:31
    
Oh sorry, I have read your question a little too quickly; I didn't see you are using Raspbmc. Well, as you said, the problem seems to be a hardware matter. Maybe someone else can help you. Anyway, if you find any solution or workaround, please share with the community :-) –  Morgan Courbet Jan 7 '13 at 21:36
    
@Julian Are you still experiencing this issue? The hid-logitech-dj driver is responsible for managing Logitech Unifying devices and should just work. I haven't seen your issue before, so are you able to check dmesg for a message like logitech-djdevice 0003:046D:C52B.0004: input,hidraw1: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:4013] on usb-0000:00:1a.0-1.1:1. The command ls /sys/bus/hid/drivers should show logitech-djdevice logitech-djreceiver. –  Lekensteyn May 10 '13 at 21:47
1  
I just tried cat /dev//input/mouse0 and it produces characters when I move the mouse and XBMC is not seeing the mouse. –  Julian Oct 2 '13 at 19:22

2 Answers 2

In digging through the C++ source code to XBMC, I noticed that two types of events are anticipated, but you may have three possible scenarios.

  1. Device is loaded at time of launch for XBMC (CLinuxInputDevices::InitAvailable) [handled]
  2. Device is "hotplugged" during execution of XBMC (CLinuxInputDevices::CheckHotplugged) [handled]
  3. Device driver reconfigured an existing device after XBMC started [not handled]

I would bet, based upon the CLinuxInputDevices::Open function, that one of those error messages appear during startup because the device driver cannot honor some of the ioctl calls. Subsequent calls to read events can't properly talk to the kernel structures, so XBMC thinks it has a device, but never initialized it properly. Unplugging and reloading the dongle is enough to trigger a hotplug event in XBMC.

In short, one of two things would need to happen. First, the driver talking to the dongle (e.g. logitech-djdevice), could unplug and replug the device into the hotplug system in order for XBMC to detect the change. Second, XBMC could trap the failed open() call (it ignores the return code now) and keep polling the device hoping it will successfully initialize.

I don't have the resources to recompile the code, so I can't submit a patch at this time.

For archive purposes, this analysis was based upon the Apr 27, 2014 checkin of xbmc/xbmc/input/linux/LinuxInputDevices.cpp. Potential error messages you might see include:

  • CLinuxInputDevice: could not open device:
  • CLinuxInputDevice: could not grab device:
  • CLinuxInputDevice device: fcntl(F_GETFL) failed:
  • CLinuxInputDevice device: fcntl(F_SETFL) failed:

Of course, I could be in the completely wrong section of the code, if that part is for keyboards only, so I'll point you to another area interested in PERIPHERAL_HID version instead of calling it an input device. If startup shows the string "initialised HID device," then the same scenarios likely still apply, just in a different part of the code that eludes me.

share|improve this answer
up vote 0 down vote accepted

I guess we will never know, because @zerolagtime's great possible answer prompted me to check. I haven't been home since May and turning the pi on found that it had updated and the problem has gone away with XBMC 13.2-BETA1 compiled on the 28th of July.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.