Bug 118748 - Multiple mice share the same input device
Summary: Multiple mice share the same input device
Status: RESOLVED INVALID
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: SaX2 (show other bugs)
Version: RC 1
Hardware: Other All
: P5 - None : Normal
Target Milestone: ---
Assignee: Marcus Schaefer
QA Contact: Klaus Kämpf
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-25 22:40 UTC by Michael Stather
Modified: 2005-10-05 15:44 UTC (History)
2 users (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Stather 2005-09-25 22:40:26 UTC
If the system has multiple mice, YaST sets up the x server so that the devices
for all mice are set to /dev/mice.
IMHO this is wrong, because /dev/mice collects all events from all associated
mice. So from the server point of view there are two mice which get exactly the
same events, no matter which one is moved. The x server should either use the
real devices, or just use on mouse (of the emulated type ps/2) in the config.
Since every mouse has its own options in the config file I think the first
option is more correct.
Comment 1 Martin Lasarsch 2005-09-26 11:01:07 UTC
Stefan, comments on this? 
Comment 2 Stefan Dirsch 2005-09-26 11:10:51 UTC
Something for Marcus.
Comment 3 Stefan Dirsch 2005-09-30 14:04:39 UTC
According to my latest comment.
Comment 4 Marcus Schaefer 2005-10-05 15:44:11 UTC
This is not quite correct. The kernel input interface combines all 
standard mouse types to one protocol (explorerps/2) and one multiplexer 
device (/dev/input/mice). The input interface also knows about the 
capabilities of the mouse and assigns it. The standard X11 mouse driver 
does only mappings from buttons and interprets the protocol. 
 
Device which are more special like synaptics touchpads or wacom tablets 
etc, etc, are not handled via /dev/input/mice but using the raw information 
from /dev/input/event[X]. The biggest problem here is that the driver 
has to take care about the device itself because the name is not persistent. 
 
Well this is not a configuration issue and almost all special drivers like 
alps,synaptics,wacom ... more to come; does it right 
 
The behavior here is correct and intentional.