Subject: Bug#564211: xserver-xorg-input-synaptics: Lost tapping after upgrading to 1.2.1-1 - msg#02303

List: debian-bugs-dist

Mail Archive Navigation:
by Date: Prev Next Index by Thread: Prev Next Index

Julien Cristau <jcristau@xxxxxxxxxx> writes:
> On Fri, Jan 8, 2010 at 13:59:50 +0100, BjÃrn Mork wrote:
>
>> Just did an upgrade:
>> 2010-01-08 11:04:22 upgrade xserver-xorg-input-synaptics 1.2.0-2 1.2.1-1
>>
>> and lost tapping in the process. The buttons still work, but I'm kind
>> of accustomed to use tapping for most of my clicking activities.
>>
>> Any advice on where to look is appreciated.
>>
> How did you configure tapping?

I used a hal fdi file as per the previous recommendations. Which I see
still are in the docs. This needs to be fixed and some note about udev
rules should be added to NEWS.

Right after sending the bug report, I realized that this is just another
example of the hal => udev transition biting users. Could we please try
to make this transition as seemless as possible, attempting to keep any
prior configuration if possible?

I hacked up this, which probably can't be used directly, but should work
as an example of how to migrate configuration from hal to udev. It will
write a new udev rule file, which could be saved as
/etc/udev/rules.d/66-xorg-synaptics.rules to override the system default:

#!/usr/bin/perl

use strict;
use warnings;
use Net::DBus;

# hardcoded filename
my $baserule = '/lib/udev/rules.d/66-xorg-synaptics.rules';

# regex telling us after which statement we'd like to insert the options
my $optionsplit = qr/^ENV\{x11_driver\}/;

# read the system rule file
open(F, $baserule) || die "Cannot open $baserule: $!\n";
my @before;
my @after;
my $ra = \@before;
while (<F>) {
push(@$ra, $_);
$ra = \@after if /$optionsplit/;
}
close(F);

# connect to system bus
my $bus = Net::DBus->system;

# Get a handle to the HAL service
my $hal = $bus->get_service("org.freedesktop.Hal");

# Get the device manager
my $manager = $hal->get_object("/org/freedesktop/Hal/Manager",
"org.freedesktop.Hal.Manager");

my @migrated;
# Get a list of all touchpads
foreach my $dev (@{$manager->FindDeviceByCapability("input.touchpad")}) {
my $tp = $hal->get_object($dev, "org.freedesktop.Hal.Device");
my $props = $tp->GetAllProperties();

if (my @opts = grep { s/^input\.x11_options\.// } keys %$props) {
warn "Migrating device specific x11_options ", join(',', @opts)," for
$props->{'info.product'}\n";
push(@migrated, "ATTRS{name}==\"$props->{'info.product'}\", \\\n");
push(@migrated, join(", \\\n", map { " ENV\{x11_options.$_\}=\"".
$props->{"input.x11_options.$_"} .'"' } @opts));
push(@migrated, "\n\n");
}
}

if (@migrated) {
print @before;
print "\n# automatically added based on hal:\n";
print @migrated;
print @after;
} else {
warn "No touchpad with x11_options found in hal - private udev rule
unnecessary\n";
}

BjÃrn

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx

Find Debian Jobs at git.net
(osdir sister site)

Thread at a glance:

Previous Message by Date:

Bug#563895: diffutils: undeclared conflict with diff<=2.8.1-12 (from lenny)

On Wed, Jan 6, 2010 at 7:14 PM, Santiago Vila <sanvila@xxxxxxx> wrote: > Nothing bad happens when 'diffutils' is installed but diff=2.8.1-12 is > not upgraded automatically to the same version as 'diffutils', so > there is no need to avoid that. > > Your problem came from removing diffutils, which was essential, > not from installing diffutils. Lets recap one last time and see which are the pros and cons and if this is a real problem. We have a renaming of 'diff' essential package to 'diffutils'. This is achieved so far by these two directives: | Package: diffutils | Essential: yes | Version: 1:2.8.1-18 | Replaces: diff and | Package: diff | Priority: extra | Version: 1:2.8.1-18 | Pre-Depends: diffutils This configuration will provide a smooth transition from lenny to squeeze. I think there is nothing to argue so far. We have 'diffutils >= 2.8.1-14" providing these essential tools: /usr/bin/cmp /usr/bin/diff /usr/bin/sdiff /usr/bin/diff3 We have 'diff <= 2.8.1-13" providing these essential tools: /usr/bin/cmp /usr/bin/diff /usr/bin/sdiff /usr/bin/diff3 Obviously, these two binary packages at these version conflict with each other. I'm reading one more time section 7.6.1 "Overwriting files in other packages" from Debian Policy and I've found that by declaring "Replaces" diffutils can overwrite files from diff. This is what I tried to explain in my previous messages and NOW I see that it is not a bug. It is not clear however what happens if diff=2.8.1-12 is purged after diffutils=1:2.8.1-18 is installed. Will dpkg remove these essential tools on postrm? These are owned by diffutils now and must not be removed because are no longer owned by 'diff' binary package. However, there is one scenario that could create problems. If someone reinstalls diff=2.8.1-12 is will override the binaries from diffutils. And this is exactly what I'm trying to accomplish: avoid diff=2.8.1-12 and diffutils>=1:2.8.1-18 to be installed at the same time. Technically this is done by adding: | Package: diffutils | Essential: yes | Version: 1:2.8.1-18 | Replaces: diff | Conflicts: diff <= 2.8.1-12 I see the following cons: - forces the removal of 'diff' on upgrade from lenny; - downgrades are not officially supported by Debian; I see the following pros: - the overwrite of essential tools is no longer possible; - the empty transitional package 'diff' is removed. This was my last attempt to explain the problem. I realize now that the initial report was wrong, but also that the adding "Conflicts:" besides "Replaces:" brings no problem and solves one minor problem. > Could we please close this bug? Yes, but please consider the above minor issue. Thanks (Just a notice unrelated to this bug report, diffutils has "Pre-Depends: libc6 (>= 2.3)" but on diff the restriction was higher to "2.5"). -- To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx

Next Message by Date:

Bug#564212: darker shade of grey needs 50 MB?!

Le vendredi 08 janvier 2010 Ã 22:36 +0800, jidanni@xxxxxxxxxxx a Ãcrit : > $ apt-file search gnome-appearance-properties > capplets-data: /usr/share/applications/gnome-appearance-properties.desktop > gnome-control-center: /usr/bin/gnome-appearance-properties > 50 MB just to have a darker shade of grey. > Is there any other solution? $ apt-cache search gtk theme switch gtk-chtheme - GTK+ 2.0 theme changer and previewer utility gtk-theme-switch - GTK+ theme switching utility lxappearance - a new feature-rich GTK+ theme switcher -- .''`. Josselin Mouette : :' : `. `' âYou did never write something helpful `- besides your trollingâ -- JÃrg Schilling -- To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx

Previous Message by Thread:

Bug#564211: xserver-xorg-input-synaptics: Lost tapping after upgrading to 1.2.1-1

On Fri, Jan 8, 2010 at 13:59:50 +0100, Bjørn Mork wrote: > Just did an upgrade: > 2010-01-08 11:04:22 upgrade xserver-xorg-input-synaptics 1.2.0-2 1.2.1-1 > > and lost tapping in the process. The buttons still work, but I'm kind > of accustomed to use tapping for most of my clicking activities. > > Any advice on where to look is appreciated. > How did you configure tapping? Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx

Next Message by Thread:

Bug#564211: xserver-xorg-input-synaptics: Lost tapping after upgrading to 1.2.1-1

On Fri, Jan 8, 2010 at 15:53:11 +0100, Bjørn Mork wrote: > Julien Cristau <jcristau@xxxxxxxxxx> writes: > > On Fri, Jan 8, 2010 at 13:59:50 +0100, Bjørn Mork wrote: > > > >> Just did an upgrade: > >> 2010-01-08 11:04:22 upgrade xserver-xorg-input-synaptics 1.2.0-2 1.2.1-1 > >> > >> and lost tapping in the process. The buttons still work, but I'm kind > >> of accustomed to use tapping for most of my clicking activities. > >> > >> Any advice on where to look is appreciated. > >> > > How did you configure tapping? > > I used a hal fdi file as per the previous recommendations. Which I see > still are in the docs. This needs to be fixed and some note about udev > rules should be added to NEWS. > Ack the doc needs updating. > Right after sending the bug report, I realized that this is just another > example of the hal => udev transition biting users. Could we please try > to make this transition as seemless as possible, attempting to keep any > prior configuration if possible? > I'd really prefer not to do that. Configuring stuff in hal or udev is just a stopgap until X grows a way to handle hotplugged devices in xorg.conf (which will happen with xserver 1.8), so I think we shouldn't recommend/document this as the way to go. Plus we have tools and protocol for runtime configuration anyway. (See http://who-t.blogspot.com/2010/01/new-configuration-world-order.html for a description of the way things are going) Cheers, Julien -- To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx

Web Hosting Reviews from OSDir.com Sister Site iBizWebHosting.com