Shotwell makes USB mouse jumpy/jerky

@probono, thanks for reporting this issue. Though, I use an USB mouse with Shotwell and I never had any problems, so we need some more info to catch this bug.

Firstly, can you please start Shotwell from a terminal in debug mode, like this:
SHOTWELL_LOG=1 shotwell | tee ~/Desktop/shotwell.log
...and then do whatever you do to make the mouse slow (i.e. attach a camera or just use the mouse for a while). Finally, close Shotwell and attach the shotwell.log file on your desktop to this bug report.

Secondly, can you describe the problems a bit more? In particular can you please answer these questions:
- Does it happen all the time when Shotwell is running or just when you have a camera plugged in?
- Does it also happen if you try it with another USB mouse? (if you have access to another one that is)
- Does the mouse return to normal when you turn off Shotwell?
- What version of Ubuntu do you have?
- What version of Shotwell do you have?
- Do you use some kind of external USB hub or is the mouse connected to an USB slow in the computer?
- Does it also happen if you try connecting the mouse to another USB port? (i.e. directly to the computer if you have one of those external USB hubs)
- Can you please save the output of the command "sudo lsusb -v" and attach that to the bug report?

Thanks.

This is no longer the case in the latest version from SVN.

I'm having the same problem mentioned above in 0.5.0/0.6.1.

- Does it happen all the time when Shotwell is running or just when you have a camera plugged in?
The problem starts as soon as I start the application and disappears when I close it.

- Does it also happen if you try it with another USB mouse? (if you have access to another one that is)
it happens only when I connect my Kensington wireless/wire mouse. No problem with logitech usb mouse

- Does the mouse return to normal when you turn off Shotwell?
yes

- What version of Ubuntu do you have?
10.04

- What version of Shotwell do you have?
0.5.0, 0.6.1

- Do you use some kind of external USB hub or is the mouse connected to an USB slow in the computer?
HP w2207h with usb ports
Apple keyboard with usb ports

- Does it also happen if you try connecting the mouse to another USB port? (i.e. directly to the computer if you have one of those external USB hubs)
Problem also happens when plugged in to the macbook directly (Kensington)
When plugged in to keyboard mouse stops working completely (Kensington)

- Can you please save the output of the command "sudo lsusb -v" and attach that to the bug report?
Output for lsub -v and dmesg attached

Btw. If I start shotwell in debug mode nothing gets written to the log file.

Hmm ... I use a Logitech wireless mouse and have not seen this problem. We use a wide variety of mices around the office here (Logitech, Dell, Microsoft, Dynex) and have not seen either.

Regarding the log file: this changed in 0.6. The command Martin supplied no longer works. If you run Shotwell like this:

% SHOTWELL_LOG=1 shotwell

You'll get a log file written to ~/.cache/shotwell/shotwell.log If you could attach that to this report, that could be useful.

Also, does your Kensington mouse have any special software installed for it (i.e. mouse assistants, notifiers, mouse button mappers, etc.)? Or are you using special drivers?

The original reporter speculated we poll the USB bus. This is technically incorrect. We use gudev to notify us when USB devices are added and removed in order to monitor for cameras. Now, gudev might be polling (although I doubt it). When gudev reports of a device attach/detach, Shotwell will scan the device bus looking for all camera-looking devices to determine what's been added or removed. It's this step I'm thinking is causing a problem. However, it should only happen when a device is added or removed (it does *not* happen continuously). I'm concerned that it's this step that's causing issues, perhaps because the mouse is not responding (or responding in an unusual way) and that either Shotwell or gudev keeps pinging it for information.

Looking over your dmesg.txt, I see this repeated every two seconds or so:

[ 4744.513164] usb 1-1.1: usbfs: USBDEVFS_CONTROL failed cmd shotwell rqt 128 rq 6 len 1000 ret -110
[ 4744.708903] usb 1-1.1: USB disconnect, address 62
[ 4744.936150] usb 1-1.1: new low speed USB device using ehci_hcd and address 63
[ 4745.036249] usb 1-1.1: configuration #1 chosen from 1 choice
[ 4745.040817] input: Kensington Kensington Ci75m Wireless Notebook Mouse as /devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1.1/1-1.1:1.0/input/input183
[ 4745.041075] generic-usb 0003:047D:1048.00AE: input,hidraw3: USB HID v1.10 Mouse [Kensington Kensington Ci75m Wireless Notebook Mouse] on usb-0000:00:1d.7-1.1/input0

I've been unable to find a definitive reference for the meaning of the -110 return code on the first line, but I've seen on message boards where people say it's a USB time-out.

Also, I don't see the Kensington mouse anywhere in the lsusb output you attached. The only mouse-type device in the list is the Apple Keyboard (does it have a trackpad on it?). When you made this log, where was the mouse attached?

marking incomplete as the information was requested.

Hi Jim,

I don't see this problem with a wired Logitech, or Bluetooth MS mouse. It only seems to affect my Kensington mouse.
No special drivers, or anything for the Kensington mouse.

Please find new lsusb (Line 612) and shotwell log files attached.

I attached two Shotwell logs, one with the Kensington mouse attached (shotwell_with_kensington_mouse.log), another without the Kensington mouse (shotwell_no_kensington_mouse.log).

I think, you were right with your assumption:

  "When gudev reports of a device attach/detach, Shotwell will scan the device bus looking for all camera-looking devices to
   determine what's been added or removed. It's this step I'm thinking is causing a problem. However, it should only happen
   when a device is added or removed (it does *not* happen continuously). I'm concerned that it's this step that's causing issues,
   perhaps because the mouse is not responding (or responding in an unusual way) and that either Shotwell or gudev keeps
   pinging it for information."

I see these lines in the shotwell log file when the Kensington mouse is attached

L 8435 2010-07-10 15:57:15 [DBG] CameraTable.vala:315: udev event: remove on 1-1.4.2:1.0
L 8435 2010-07-10 15:57:15 [DBG] CameraTable.vala:315: udev event: remove on 1-1.4.2
L 8435 2010-07-10 15:57:15 [DBG] CameraTable.vala:315: udev event: add on 1-1.4.2
L 8435 2010-07-10 15:57:15 [DBG] CameraTable.vala:315: udev event: add on 1-1.4.2:1.0

BR// Rupert

The log you attached when the Kensington mouse is attached: Were you attaching/detaching the mouse during the run, or did you simply run Shotwell with it already attached?

I ran Shotwell with the mouse already attached.

I have the exact same issue with my Kensington Expert Mouse. Wired USB plugged directly into the computer.

A couple of users have now reported this problem, so I've created a ticket at http://trac.yorba.org/ticket/2269 . We'll order a Kensington mouse (they're cheap) and investigate a little bit.

Just saw the issue closed as worksforme on yorba. Which Kensington mouse did you guys purchase? Maybe this means it's not all Kensington devices which could also mean it's not just Kensington devices. At any rate, my Expert Mouse (which is actually a poorly named trackball) is definitely wigging out with only Shotwell. I've been using Ubuntu for many years and have never seen this behavior, would love to dump F-Spot for Shotwell, and am basically pleading to get this looked at again. I'd be happy to provide whatever data you need, maybe a donation towards your very own Expert Mouse to reproduce the issue?

Stephen,

at Yorba we purchased a Kensington Ci75m Wireless Notebook Mouse, since this was the mouse mentioned in the log output from Rupert H. above. We have heard your plea and will reopen the ticket, though there may not be much we can do until we can reproduce the problem here. If I search Amazon for [kensington expert mouse] I see a bunch of results, so which mouse do you have, exactly? Could you additionally answer all the questions in Martin's comment #1 above? Thanks!

Thanks Adam, I appreciate the responsiveness and, as a developer myself, understand the difficulty in tracking down something you can't reproduce. This is the trackball: http://www.amazon.com/Kensington-Expert-Optical-Trackball-64325/dp/B00009KH63/ref=sr_1_1?ie=UTF8&s=electronics&qid=1279698338&sr=8-1

- Does it happen all the time when Shotwell is running or just when you have a camera plugged in?
All the time, starts as soon as the program loads.

- Does it also happen if you try it with another USB mouse? (if you have access to another one that is)
Tried with a logitech cordless trackball and did not see the issue

- Does the mouse return to normal when you turn off Shotwell?
Yes, immediately.

- What version of Ubuntu do you have?
10.04

- What version of Shotwell do you have?
0.6.1

- Do you use some kind of external USB hub or is the mouse connected to an USB slot in the computer?
Plugged directly into the computer, rear USB port.

- Does it also happen if you try connecting the mouse to another USB port? (i.e. directly to the computer if you have one of those external USB hubs)
Tried a front USB port and one of the ports on my monitor, same behavior.

Hi,

I can confirm this bug.

Specs:
* Logitech MX310 (USB Mouse)
* Plugged in via active (powered) usb hub
* Chipset: nForce 4 Ultra
* Shotwell: 0.5.0+dfsg-1.1 (from ubuntu repos)
* Shotwell 0.7.2-1~lucid1 (from your repo)
* Ubuntu lucid amd64
* Yes, stops when shutting down shotwell
* Yes, same behaviour on any other port

Hardware Specs:
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10)
 Subsystem: ASUSTeK Computer Inc. Device 815a
 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20
 Memory at d3003000 (32-bit, non-prefetchable) [size=4K]
 Capabilities: <access denied>
 Kernel driver in use: ohci_hcd

00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20)
 Subsystem: ASUSTeK Computer Inc. Device 815a
 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21
 Memory at feb00000 (32-bit, non-prefetchable) [size=256]
 Capabilities: <access denied>
 Kernel driver in use: ehci_hcd

Bus 002 Device 025: ID 046d:c01b Logitech, Inc. MX310 Optical Mouse
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor 0x046d Logitech, Inc.
  idProduct 0xc01b MX310 Optical Mouse
  bcdDevice 18.00
  iManufacturer 1 Logitech
  iProduct 2 USB-PS/2 Optical Mouse
  iSerial 0
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 34
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower 98mA
   [etc.]

Dear Ubuntu desktop teams,

since there is no progress on this bug and this bug is a showstopper - meaning, I cannot use this software at all (therefore a »condicio sine qua non«).

Because of this, I am willing to help you debbung shotwell. And yes, it is indeed a shotwell bug, since kopete's photo manager and F-Spot do not show this behaviour. Since this bug might affect a lot of users not using launchpad, I'd recommend a slightly higher priority.

If you need any further information, please let me know.

Thanks in advance.

bmhm,

Glad you're willing to help out. Could you do the following?

1. Can you disconnect the active USB hub and plug the mouse into your computer directly? In that case, does the problem still occur?

2. Run this command:

$ sudo lsusb -v > usb.txt

Then attach the usb.txt file to this ticket (or the upstream ticket at http://trac.yorba.org/ticket/2552 - either is fine).

3. Run Shotwell like this:

  $ SHOTWELL_LOG=1 shotwell

Reproduce the problem (which I assume happens immediately and constantly) then exit Shotwell.  Then attach the file ~/.cache/shotwell/shotwell.log to this ticket.

4. If you disconnect your mouse entirely and then run Shotwell and control it via the keyboard, does Shotwell seem to run normally?

Is shotwell using libmtp or mtp code? We got similar issues since lucid in music players doing mtp devices detection for example

see bug #610036 for example

bug #559892 was similar as well bug has been fixed in recent ubuntu versions

Ok, for the record that's the libmtp bug which as fixed:
http://libmtp.cvs.sourceforge.net/viewvc/libmtp/libmtp/src/libusb-glue.c?r1=1.286&r2=1.287

The comment suggests HDI devices doesn't like the device detection

"HID devices" rather

Sebastien,

This is all very interesting! We do not use MTP (or libmtp), but we do use gphoto2, which does a device query in order to locate connected cameras. We also query the udev system looking for cameras on our own in order to properly associate a USB ID with gphoto2's names. (Long story.)

Although I can't say the bugs you've linked to completely shed light on what's going on here, it does point to some possible problems. It's interesting that the Kensington mouse comes up again in another bug and is specifically mentioned in the patch. As mentioned earlier, we acquired the mouse but couldn't repro it here.

I need more time to look at all this information more thoroughly. Thanks for the links!

For anyone out there who still has this problem, could you try the following test and tell me what happens?

1. You'll need to have gphoto2 installed. To get it, run this:

$ sudo apt-get install gphoto2

2. Run this command:

$ gphoto2 --auto-detect

3. When it completes, run it again. Try doing this a few times, waiting a second or two between each run.

4. While it's scanning your system, try moving the mouse.

Essentially, I'm interested in knowing if you see the same kind of problem you see while running Shotwell.

If you could tell me (a) how long it takes for the command to complete and (b) what version of gphoto2 you're running:

$ gphoto2 --version

that would be helpful as well.

Hi Jim,

yes, I have exactly the same behaviour. It lists no devices, but half a second later my mouse gets disconnected again. It's fully reproducible.

Oct 9 18:17:17 oberth kernel: [ 1557.711954] usb 2-3.3: new low speed USB device using ohci_hcd and address 5
Oct 9 18:17:17 oberth kernel: [ 1557.839138] usb 2-3.3: configuration #1 chosen from 1 choice
Oct 9 18:17:17 oberth kernel: [ 1557.850080] input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3.3/2-3.3:1.0/input/input6
Oct 9 18:17:17 oberth kernel: [ 1557.850453] generic-usb 0003:046D:C01B.0003: input,hidraw0: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:02.0-3.3/input0
Oct 9 18:17:22 oberth kernel: [ 1562.433023] usb 2-3.3: USB disconnect, address 5
Oct 9 18:17:22 oberth kernel: [ 1562.620043] usb 2-3: reset full speed USB device using ohci_hcd and address 2
Oct 9 18:17:23 oberth kernel: [ 1563.152016] usb 2-3.3: new low speed USB device using ohci_hcd and address 6
Oct 9 18:17:23 oberth kernel: [ 1563.279191] usb 2-3.3: configuration #1 chosen from 1 choice
Oct 9 18:17:23 oberth kernel: [ 1563.290765] input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3.3/2-3.3:1.0/input/input7
[etc...]

$ gphoto2 --version
gphoto2 2.4.5

Copyright (C) 2000-2008 Lutz Müller und andere

gphoto2 comes with NO WARRANTY, to the extent permitted by law. You may
redistribute copies of gphoto2 under the terms of the GNU General Public
License. For more information about these matters, see the files named COPYING.

Diese Version von gphoto2 benutzt die folgenden Softwareversionen und Optionen:
gphoto2 2.4.5 gcc, popt(m), exif, cdk, aa, jpeg, readline
libgphoto2 2.4.8 gcc, ltdl, EXIF
libgphoto2_port 0.8.0 gcc, ltdl, USB, serial without locking

Hope this helps.
Perhaps I can use the gnu debugger and run the detection step by step, so we know where in the code this problem occurs. Is that possible?

Regards,
Ben

I have same problem with USB Wacom tablet and Shotwell. When i start Shotwell, my tablet led blinks and kernel log displays things like "usbfs: USBDEVFS_CONTROL failed cmd shotwell rqt 128 rq 6 len 1000 ret -84" until my screen goes black. Same thing happens with Rhythmbox when I try to enable Portable Players - MTP plugin. Some versions of F-Spot does same as Shotwell and Rhythmbox for my Wacom USB tablet. Hope this helps.. unfortunately i had to uninstall Shotwell and go with Gthumb. I liked Shotwell all 10 seconds before my screen went black :)

bmhm,

Okay -- that tells me that the problem is occurring when gphoto2's camera detection routine is executed. It's creating a vicious loop in Shotwell: Shotwell goes to detect if any cameras are present in the system, causing the mouse (or other device) to disconnect and reconnect. Shotwell is notified that a device has connected to the system and it goes to detect if any new cameras are present in the system ... on and on.

You're running an old version of gphoto2. Could you upgrade to the latest (2.4.10.1)? It's here:

http://sourceforge.net/projects/gphoto/files/

Then see if you can reproduce your problem in Shotwell.

Thanks,

-- Jim

To everyone still having this problem: We're curious what release of Ubuntu you're using. That will give us some idea of what version of gphoto2 you're using, which seems to be the root of the problem.

Marko: One of the previous commenters reported a link that suggests this problem was fixed in libmtp, which may solve your problem with Rhythmbox. You might verify if you have the latest version installed.

-- Jim

Hi Jim,

running Lucid Lynx (10.04) here. I already updated shotwell to maverick's version, as you can see above.

I can give you the results of an updated gphoto next week or so. First I'll try the version from maverick. If that fails there is still the version from sourceforge available.

Since shotwell isn't the default photo manager in 10.04, you might be happy with the information that I'm going to upgrade my system to 10.10 soon.

Also, if it helps, there was not such an issue when using digiKam (KDE photo manager).

-- Ben

I am also experiencing this problem running Ubuntu 10.10 I would like to run Shotwell in preference to F-spot or Picasa but, as things stand at the moment, the problems with the mouse make it virtually unusable.

I tried the gphoto2 autodetect experiment and found that it always locked up the mouse.

The version shipping with Ubuntu 10.10 is gphoto2 amd64 2.4.5-2. This is well behind the latest 2.4.10 release so I tried installing from the tarball. However, I then started to get into further dependency issues with libusb.

I agree with bmhm that this problem is a showstopper and that many end-users will simply move back to Picasa or F-Spot without anyone even knowing that they tried Shotwell.

It may be that the problem is fixed in 2.4.10 in which case we need to be contacting the Ubuntu release team to get them to ship the latest version. Do you know the contact details of the right person in Ubuntu? If so I'm happy to chase them up a bit.

Thanks

Neil

I subscribed the »ubuntu stable releases update team«. Hopefully any of them knows what needs to be done.

To all others: Just below the bug's title there is a line that says "This bug affects n people". If it doesn't say "you and n other people", please click the exclamation mark next to it and say "yes, it affects me". This way this bug might get more attention.

Thank you for your help.

I am concerned that this bug has been assigned an importance of "low" or "unknown". I think it should be higher for the following reasons:- The bug does not just affect the kensington mouse, it makes Shotwell virtually unusable for those affected and there is no simple work-around.

As mentioned in my previous post - if the problem has been fixed in the latest version of Shotwell then we now need to try to get Ubuntu to ship this updated version of Shotwell. If this is the case then please let us know....

Shotwell looks like a great program I really want to be able to use it.

thanks, Neil

gypsy_roadhog (and everyone else)

Just to be clear, I don't control the Importance for the Ubuntu side of things. This bug on our Trac system is marked High and we're taking it very seriously. What's impacting us the most right now is that we can't reproduce this in-house, making it difficult to debug. We've tried reproducing this on Maverick and Lucid, using both older versions of gphoto2 (2.4.5) and the latest. It does appear to be a gphoto2 problem in the sense that when we ask it to auto-detect cameras it's causing the mouse to hang. It's possible the problem is in libusb itself (which gphoto2 relies on to talk to the cameras).

I realize that saying all this doesn't solve your bottom-line problem, but we are looking into it! It may be that we have to work around this in Shotwell somehow. That "somehow" is the $64,000 question at this moment.

-- Jim

Unsubscribing ubuntu-sru. As long as we don't have a fix/workaround, there's nothing to SRU.

Hi Jim
I've read and understood your message - I understand the problems of debugging a fault you can't reproduce. However, giving us a clear statement of where we are - without making it sound as though we were simple - was really helpful and much appreciated.

Having said all of that I have made my problem go away. I originally installed the 10.10 beat release and the applied all of the upgrades until it was up to date with the live version - everything worked fine apart from the Shotwell/gphoto2 mouse problem.

So anyway I downloaded and installed copy of the full 10.10 amd 64 release. This is a pain as I need to install and configure all of the extras that I had working before.

Well after all of the Shotwell seems to be working well with no mouse glitches.

Neil

I just found a workaround:

Plugging in my camera stops gphoto2 as well as shotwell from triggering this behaviour. Well, this is where it gets odd for me. Anyway, this is not a practicable workaround, since battery life is limited.

By the way, I just updated libusb and gphoto just before trying this:
libgphoto2-2 2.4.8-0ubuntu2
libgphoto2-port0 2.4.8-0ubuntu2
libusb-0.1-4 2:0.1.12-15ubuntu2
libusb-1.0-0 2:1.0.8-2
libusb-dev 2:0.1.12-14ubuntu0.2

Hope it helps and thanks for looking into this.

All this makes for more interesting data points. gypsy_roadhog, if I understand your message correctly, you're saying you performed all the upgrades to the 10.10 release with no success. But, when you did a full install of 10.10 AMD-64, the problem went away. Were you running a 64-bit version of 10.10 before the full upgrade?

bmhm, this info is good too, but I'm curious if upgrading libusb and gphoto2 was sufficient without connecting your camera. In other words, do you still see the behavior if the camera is not connected? I'm assuming you do, but I just want to double-check all possibilities.

-- Jim

Hi Jim

I'm saying that I installed a beta copy of 64-bit 10.10 and applied the upgrades as they became available over the next few weeks (using update manager). The system was stable and I was not aware of any problems apart from the Shotwell gphoto2 problem. Using synaptic to reinstall Shotwell didn't cure the problem.

Just in case "something funny" had crept in along the way I then decided to install a clean version of the live release of 64-bit 10.10 system. Shotwell is now working perfectly (and I'm really pleased with it)

regards

neil

Marking as New as we believe this to be a fully valid and reproducible bug (just not reproducible for the developers).

I have yet another simple test for anyone out there still experiencing this problem. Could you please do the following:

$ sudo lsusb -v

and report back if your mouse freezes up? You might need to run the command a few times.)

Thanks!

Hello everyone.

Thank you for your patience. I was not able to answer earlier, sorry for that.

Jim, yes - I still see this behaviour, if my camera is not connected. Sadly. On the other hand this allowed me to run lsusb -v (as root), so you can see the differences between shotwell running (scanning.txt) and shotwell off (nonscanning.txt). And yes, my mouse still freezes, as it still gets disconnected as can be seen in /var/log/messages.

Spoiler alert: The difference isn't that exiting. It is just the mouse which is missing.

Hello again,

in #ubuntu-devel, they suggested this bug might in fact be related to gphoto2 and/or libgphoto2. It should use udev instead of libusb for monitoring cameras.

Please also don't forget Sebastians link to libmtp's source code tracker. Both mice (Ruperts and mine) have "HID" as interface class. Now, libgphoto2 doesn't have any checks on this [I found it in: libgphoto2-*/gphoto2-abilities-list.c in libgphoto2, function gp_abilities_list_detect_usb()].

So as a workaround, I'd rather give this bug in the hands of the libgphoto2-devs to add the same workaround which is being used in libmtp Sebastian showed us. Also, ebroder in #ubuntu-devel suggested that gphoto2 rather should use udev to monitor for new devices. But this would have a lot more impact on the whole distribution. Therefore this would be a goal to a new major version, perhaps.

Αs a workaround:
* attach a camera while using shotwell (verified with »works-for-me«)
* add HID-detection to [lib]gphoto2
* perhaps, instead of workaround #1, create a virtual dummy camera, which is then being hidden by shotwell. Ugly, but *might* work.

Since I am now convinced, gphoto2 should update their packages, I'll add them here as well.

Hope this helps.
Best Regards,
Ben

accidently selected gPhoto2 instead of libgphoto

I do think this is a libgphoto2 bug and I can see why talking to udev is the way to go. The real fix is very likely akin to the MTP patch that was linked to earlier.

I've filed a bug on gphoto2's ticketing system:

https://sourceforge.net/tracker/?func=detail&aid=3101045&group_id=8874&atid=108874

Subscribing Martin to this bug since he's the one who does know better about that part of the stack, Martin do you think you could do the described gphoto hack for Ubuntu?

I've noticed this Kensington USB mouse issue due to the fact of being part of "vboxusers" group. So, anyone could confirm that they are using VirtualBox software and have included their users to vboxusers group to enable USB on guests?.

In addition to Shotwell, this problem appears on Rhythmbox so they possibly are in conflict whit virtual USB interface of Virtual Box.

Confirmation please.

Now this is where it gets odd. Yes, my user is in the virtualbox group, as I am a vbox user. But.... I don't have this issue with Rhythmbox.

Starting a guest session and then starting shotwell confirms your assumption. Mouse works flawlessly as a guest user. On the other hand, just unloading the vbox-modules didn't help (using rmmod).

I'd say, pretty good guess! Confirmation hereby given.

What I do is not to be part of vboxusers for "normal host use" and when I need to use a VM whit USB I add my user to the group but I hope this will be fixed on next vbox releases.

I have a Kensington Expert Mouse (USB trackball) and have the same issue. I also have Virtual Box installed and am a member of the vboxusers group. The issue does not exist in the guest session either.

probably the vboxuser group membership allows accessing all USB devices by the respective user.

only this way libgphoto2 could actually open your mouse usb device and cause this usb reset behaviour.

Having users able to access all USB devices is a security risk btw. ;)

I'm not sure I understand what's being said here -- is it that (a) this happens when VirtualBox is installed, or (b) when Shotwell is run inside a VirtualBox session?

I'd be curious if anyone still having this problem could write here if they're using VirtualBox or have it installed.

Jim, we're not running Shotwell inside a vbox. We got Shotwell on our "real" system, and virtualbox installed next to it. Virtualbox creates a user group, which your user has to be part of in order to use virtualbox correctly. This group "vboxuser" grants raw access to USB devices - so it seems.

That's what I suspected, but wanted to be clear. I did try today downloading VirtualBox, adding myself to the vboxusers group, reboot, and run Shotwell (outside and inside the virtual machine) with the Kensington wireless mouse and trackball, with and without a USB hub, and failed to reproduce this.

Not saying this isn't an interesting path to follow, but it wasn't an immediate win on my end. Perhaps there's another piece to the configuration puzzle I'm missing here.

Perhaps it only occures on specific mice? So both the vboxusers-group and a Logitech/Kensington mouse are required for this bug to occure?

I'll try anoter mouse model (Logitech, too, sadly) later.

My mouse (apple magic mouse) was also jerky while running shotwell. I have replaced VirtualBox which was installed from deb package downloaded from VirtualBox site, to VirtualBox OSE from ubuntu software repository.
It solved mouse problems.

I've just closed the upstream ticket with these comments:

It's become clear that this problem is related to VirtualBox.  It seems to affect users who are running a version of VirtualBox that can proxy USB events on the host to a virtual machine (the open source version of VirtualBox does not do this).  As such, it's not a Shotwell bug.  Marking as wontfix.

If anyone sees this behavior who does have VirtualBox installed, feel free to reopen.

Created and added upstream bug.

thanks for sending this bug to virtualbox developers.

> It seems to affect users who are running a version of VirtualBox
> that can proxy USB events on the host to a virtual machine
> (the open source version of VirtualBox does not do this).

I'm marking the virtualbox-ose task as Invalid. The bug only affects the proprietary version of VirtualBox.

I upgraded to virtualbox 4.x, and am using 10.10 by now.

The bug doesn't occur any more. Can someone confirm this, please?