syndaemon doesn't accept device name option
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xserver-xorg-input-synaptics (Ubuntu) |
Invalid
|
Low
|
Unassigned |
Bug Description
Binary package hint: xserver-
Since SHMConfig option is not needed, there is no way to set the right target device for syndaemon when there are two touchpads or more.
This is a patch for syndaemon to add a -n option for the device name
http://
I suppose that the same thing could be done for synclient.
More information here
http://
ProblemType: Bug
Architecture: amd64
Date: Wed Nov 11 15:00:36 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
MachineType: Acer, inc. Aspire 5920G
NonfreeKernelMo
Package: xserver-
ProcCmdLine: BOOT_IMAGE=
ProcEnviron:
PATH=(custom, user)
LANG=it_IT.UTF-8
SHELL=/bin/bash
ProcVersionSign
RelatedPackageV
xserver-xorg 1:7.4+3ubuntu10
libgl1-mesa-glx 7.6.0-1ubuntu4
libdrm2 2.4.14-1ubuntu1
xserver-
xserver-
SourcePackage: xserver-
Uname: Linux 2.6.31-15-generic x86_64
dmi.bios.date: 06/18/2008
dmi.bios.vendor: Acer
dmi.bios.version: v1.3813
dmi.board.name: Chapala
dmi.board.vendor: Acer, Inc.
dmi.board.version: Not Applicable
dmi.chassis.type: 1
dmi.chassis.vendor: Acer, Inc.
dmi.chassis.
dmi.modalias: dmi:bvnAcer:
dmi.product.name: Aspire 5920G
dmi.product.
dmi.sys.vendor: Acer, inc.
fglrx: Not loaded
system:
distro: Ubuntu
architecture: x86_64kernel: 2.6.31-15-generic
tags: | added: karmic |
Changed in xserver-xorg-input-synaptics (Ubuntu): | |
status: | Incomplete → Invalid |
Hi mohrtutchy
Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner. There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. If you could test the current Ubuntu stable release(maverick ubuntu 10.10), this would help us a lot. If you can test it, and it is still an issue, we would appreciate if you could upload updated logs by running apport-collect <bug #>, and any other logs that are relevant for this particular issue