After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 347792 - Totem sometimes disables mouse devices when built with lirc devices
Totem sometimes disables mouse devices when built with lirc devices
Status: RESOLVED NOTGNOME
Product: totem
Classification: Core
Component: Movie player
1.4.x
Other Linux
: Normal normal
: ---
Assigned To: General Totem maintainer(s)
General Totem maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2006-07-17 14:53 UTC by Chris Lord
Modified: 2008-12-08 14:25 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Description Chris Lord 2006-07-17 14:53:55 UTC 
Please describe the problem:
When totem is built with lirc support and a lirc-supporting device is present, it sometimes will disable the mouse device (that is to say, if you read from the device node, all input suddenly stops as soon as totem is loaded). This behaviour is consistent across a system session, but does not always occur. When totem is quit, the mouse device then resumes normal functionality.

Steps to reproduce:
1. Build totem with lirc support
2. Run it with a lirc device present


Actual results:
The mouse device has stopped working (possibly)

Expected results:
The mouse device would continue to work.

Does this happen every time?
No, intermittently, but consistently per system session.

Other information:
If you plug a second mouse in, during or previous to X starting, this mouse appears to be unaffected by this bug.
Comment 1 Chris Lord 2006-07-17 14:55:30 UTC 
In addition, this is on Ubuntu Linux (dapper), on amd64.
Comment 2 Sebastien Bacher 2006-07-17 15:13:25 UTC 
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/totem/+bug/38594
Comment 3 Bastien Nocera 2008-12-08 14:25:50 UTC 
As stopping the lirc service fixes the problem, this is likely a problem in LIRC, maybe in the LIRC kernel-space drivers (or maybe in the LIRC configuration). Closing as NOTGNOME.