Created attachment 306897 [details]
anaconda.xlog

Created attachment 306898 [details]
dmesg

Created attachment 306900 [details]
Xorg.0.log

Created attachment 306901 [details]
Xorg.0.log.old

Let's forget bug 164378 -- it is most likely red herring (things have really
changed a lot since Fedora 4 and we haven't seen anything like that since much).
So, let's treat this as a new bug.

Hi,

Is there any development on this case?
Can we have some update, please?

Thanks!

Istvan

I have the same issue. It seems to be mitigated somewhat by having an external
mouse and specifying the protocol automatically for that one (imps2 for me), but
the issue doesn't go away completely.

I'm also having issues of getting random junk keyboard input (I haven't tried
compiling a kernel of my own without any kind of mouse support, but I guess that
would solve the junk input problem).

Setting the default runlevel to 3 in /etc/inittab still makes me get tons and
tons of junk input, seemingly from the keyboard (I'm a notoriously lazy bastard;
my left thumb rests more or less constantly on the touchpad). It seems the input
is identical to that of pressing F7 (^[[18~) about a billion times per second.

n the command line, it only shows up as a string of '~'. The keyboard is useless
while those are being printed and a short while after, while the kernel tries to
reinitialize the mouse pointer.

The touchpad and external mouse both work flawlessly when booted into Windows
Vista, so hardware malfunctions can safely be ruled out.

I'll log back to windows now and try to attach some dmesg output. It's littered
with strings like this (from memory):

    Bad input from KBC - bad parity

There are about 30-60 of those, followed by "trying to reinitialize input device
on /devices/input/serio<x>", followed by a failure message, followed by a "New
input device registered at /devices/input/serio<x+y>" (or some such). While the
re-initializing goes on, keyboard and both the mice are frozen and nothing can
be done to fix it.

I'm well-versed in git (I helped write the silly thing) and I work as a C
programmer, so I'd be happy to help resolving this issue.

The problem is present with the latest fedora kernel (2.6.25.9-76.i686, I think)
as well as with latest master from Linus' tree (v2.6.26-rc9-5), and I noticed it
at the end of the fedora 8 period as well (I just upgraded), so I don't think
it's an Xorg issue.

This is indeed a kernel issue. When booting with the 2.6.23.1-42.fc8 kernel, I
get the (much more pleasant) "tapping doesn't work" issue and the touchpad is
properly recognized as an "AlpsPS/2 ALPS GlidePoint" device rather than a "PS/2
Generic Mouse" in the dmesg output.

As a work-around, adding "psmouse.proto=bare" to the kernel boot options sort-of
works, but seems to cause a conflict between my USB mouse and the touchpad, so
that the external mouse moves sluggishly 5-10 seconds out of every two minutes
(to the point where it looks frozen). Not a big issue, but annoying to the point
where this was still itching enough for me to scratch it.


It's worth noting that I was unable to use the nvidia kernel module with the
2.6.23.1-42 kernel though, as the latest (and working) nvidia module doesn't
come pre-compiled for 2.6.23.1-42. I've been burned too many times before from
manually installing it to feel safe doing that again.

It might be worth setting hardware to i686 instead of x86_64. I don't think Dell
ships XPS laptops with 64 bit CPU's (although I can't imagine it being relevant
for this case, since the mouse input drivers all work on 8-bit fields anyways).

Will try my way up through the kernels and holler when I know the first one that
breaks. Once I get a narrow enough window I'll start bisecting and bring this to
linux-input@vger.

Incidentally, do you happen to have any quick way of testing new kernel images?
I've tried googling/asking around, but I haven't found anything so far that
doesn't involve creating ramdisks and rebooting (which works, but it's slow).

kernel-2.6.24.3-12.fc8 (and all later kernels) exhibits the problem.
kernel-2.6.23.1-42.fc8 (and presumably earlier) "works" (apart from touchpad
tapping, that is).

I have no idea which (git) commits these two kernels were built from. I'm having
a hard time matching the linux-2.6.23 tarball to the v2.6.23 tag of the
"official" linux git repo, so trying to find the exact (tree) match for when
I've added the patch-2.6.23.1 is all but impossible. It seems one could start a
bisect with

    git bisect start v2.6.24 v2.6.23

though and almost certainly get some good mileage out of it. There are two
merges in that range, but also some really trivial typo-fixes. The most likely
culprit is actually the first one.

I'll do that now and see where it leads to.

As posted to linux-input@vger:

This problem is not in v2.6.26-rc9-56-g6329d30 from Linus' tree
(6329d3021bcfa9038621e6e917d98929421d8ec8). Now it's just the
touchpad tapping that doesn't work any more, which I personally
don't really care about.

It would be nice to see a quick kernel upgrade to 2.6.26 once
it goes stable so I don't need to use self-compiled kernels
anymore.

I'll send my kernel build config as attachment in a new post soon.

Created attachment 311553 [details]
kernel build configuration

This is the kernel build .config I'm using at the moment, with
v2.6.26-rc9-56-g6329d30 from Linus' tree
(6329d3021bcfa9038621e6e917d98929421d8ec8).

For future references; It would be nice if CONFIG_IKCONFIG and
CONFIG_IKCONFIG_PROC could be set to M for fedora kernels. That way one won't
have to look all over the web to find the build-options used, making it easier
to debug things like this on ones own.

It would be even nicer if there was a git repository somewhere with one branch
for each supported arch (it doesn't matter if the branches get rewritten every
time there's a new release) so one can easily check the actual code ones own
kernel was built from and also make modifications to it.

Still no go with kernel-2.6.25.10-86.fc9.i686. v2.6.26 from Linus' tree works
nicely though.

Reassigning to kernel.

(In reply to comment #11)
> 
> For future references; It would be nice if CONFIG_IKCONFIG and
> CONFIG_IKCONFIG_PROC could be set to M for fedora kernels. That way one won't
> have to look all over the web to find the build-options used, making it easier
> to debug things like this on ones own.

The config is always installed as /boot/config-$(uname -r)
 
> It would be even nicer if there was a git repository somewhere with one branch
> for each supported arch (it doesn't matter if the branches get rewritten every
> time there's a new release) so one can easily check the actual code ones own
> kernel was built from and also make modifications to it.

The full SRPM used to build the kernel is always made available.

Complete directions for how to build your own kernel from the SRPM are here:

  http://fedoraproject.org/wiki/Docs/CustomKernel

Thanks guys the fantastic effort to get this issue fixed.
The recommendation to include psmouse.proto=bare unfortunately didn't work in my
case and I'm not a kernel guru to play with the different trees.

The latest comment on https://bugzilla.redhat.com/show_bug.cgi?id=164378#c13
however seems to fixed my issue and even though I still can't tap on the
touchpad to click on objects, at least I can now use the mouse to do the work on
my M1530

"Pass the kernel parameter i8042.nomux=1 at boot and the issue will not affect
you XPS M1530 with the synaptics touchpad.
I saw this issue manifest when I moved from BIOS revision 0.6 to BIOS revision
0.8 on my own XPS M1530."

The entry in grub.conf works for me too but still no tap possibility on my M1530 BIOS A09.

I have tried Fedora 10 Alpha Live x86_64 using USB stick and not had a problem on booting in to GNOME.

A new development on this issue...

I use Gnome on this laptop and when I suspend the machine, close the lid then restart the session again, suddenly the mouse driver detects the taps and works as normal.
I haven't changed anything extra, only added the 'i8042.nomux=1' parameter to the kernel boot ones.

Now the mouse is working fine with all the features I think if I boot into Fedora, login, suspend the host, then revive it again.
I can even use up/down and left/right scrolls on the side of the touchpad.

weird....

I have found an article on fedoraforum.org which is called " How do I enable 'tap to click' on mousepad?"

There it is suggested the following entry be added to xorg.conf which will then allow tapping function. I shall try this when I get home if you can it might be worth giving it a go too.

#Another section for Touchpad
Section "InputDevice"

       Identifier "Touchpad"
       Driver "synaptics"
       Option "SendCoreEvents"
       Option "Protocol" "auto-dev"
       Option "TapButton1" "1"
       Option "TapButton2" "2"
       Option "TapButton3" "3"
       Option "SHMConfig" "on"

There is also info ref the suspend / resume (similar?) here:

https://bugzilla.redhat.com/show_bug.cgi?id=439386

Dear DEV people,

Just wondering with only a couple of days left until the official release of the new Fedora if there's any chance to get this issue fixed in v10?

Thanks!

Fixed in:
2.6.27.7-51.fc9
2.6.27.7-126.fc10

kernel-2.6.27.7-53.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/kernel-2.6.27.7-53.fc9

kernel-2.6.27.7-53.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

kernel-2.6.27.7-53.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.