at least with this recording, I cannot reproduce this, the pointer moves in two movements towards the top-left. Was this a recording that reproduced the issue on your box?

Is there smething else running that may affect pointer position? synergy or something similar?

Can you try under GNOME on Wayland vs GNOME on Xorg to see if there's a difference?

does sudo libinput-debug-events show events from any other device as you move? Attach the output here please, that should also show up any jumps.

Yes, those two swipes were an attempt to reach the top left corner.  One swipe didn't get there,  and some kind of recentering happens at the begging of the second swipe so that it still didn't reach to top-left corner.

I don't know of any other application that may affect pointer position.

I removed gpm and verified that that wasn't the cause.

The same problem occurs on the dm screen immediately after a fresh reboot and before first logi; so there were no user applications started.

I tried with gdm and with lightdm.  No diff

The problem now exists on a second laptop:

    System Information
        Manufacturer: Dell Inc.
        Product Name: Latitude E6510
        Version: 0001

     Touchpad:
        /dev/input/event7: AlpsPS/2 ALPS DualPoint TouchPad

I tried running libinput-debug-events  (I'll attach output)

One thing I noticed was the absence on any event for touching the mousepad.  The recentering occurs on touch.

Created attachment 1236964 [details]
libinput-debug-events output - 2 strokes LR-TL

Note - no finger up/down events recorded between strokes.   Recentering happens at the beginning of the stroke.

I'm seeing additional sporadic issues that may be related ..

    - one time the real mouse started being contrained in its movement...
    - shortly after, the system hung and had to be rebooted.

    - if I use the mousepad to move to the edge of a terminal window
      (a small one, in the center of the screen)  then there is a lot of
      jiggling of the pointer,  as if there were two event streams trying
      to move it.   No events are  recorded by libinput-debug-events when
      this jiggling is happening.

hmm, you're right, there is nothing in the libinput debug log that would indicate bad cursor movement, the movement is consistently towards the negative x/y axes.

when the jiggling happens, do you see any events on the event nodes? run sudo evemu-record against the various /dev/input/eventX devicess and see if you see events for them. If not, then this must be a bug in X somewhere - if the device works in gdm this means wayland is working fine.

Does the journal show any error messages?

Also, any chance you can film a short video that shows the effect. Makes it easier to understand what's going on.

"consitently towards the negative x/y axis"  may be an artifact of my tests strokes always being from LR to TL.  I would have said something like "spontaneously centering"

I ran "sudo evemu-record"  against all 14 events on the HP laptop.

The only oddity was a continues stream of events from the "accelerometer"
(Why would I need an accelerometer in a laptop?  Can I disable it?).   See attached.

Nothing showing up in "journalctl -f" when I try to erach the corned from the touchpad.


I think earlier I might have claimed that the touchpad was working at gdm time.    That isn't true today.  Also tried LightDM,  with same problems.

The USB mouse usually works ok,  although at least once those motions wer also constrained into a small space,   followed shortly by a system crash.

Isn't it more likely to be a wayland bug?  Given that both laptops have works fine with X11 until a couple of weeks ago?

Created attachment 1237071 [details]
output from "sudo evemu-record /dev/input/event9"

That should read "...a continuous stream of events..."

Working on your movie ....

I can't reproduce the jiggling on the HP laptop.    I saw it earlier today at work on the Dell laptop.   I'll record your movie tomorrow when I'm back at work.

does xinput list show the accelerometer device? that cursor jump you describe is a common issue when an accelerometer is added as input device.

What's the most recent X log as shown in journalctl  -ef _COMM=gdm-x-session

on the HP laptop:
    - no jiggling
    - evemu-record /dev/input/event9  - accelerometer - shows a continuous stream of events
    - xinput  - does *not* list an accelerometer   (see attached: xinput_hp_laptop.txt))

on the Dell laptop:
    - jiggling
    - tried evemu-record on all 15 events - no accellerometer, no other events occuring during simple touchpad strokes
    - xinput   - (see attached: xinput_dell_laptop.txt)

CONCLUSION:  jiggling is *not* due to an accelerometer on the Dell


"journalctl  -ef _COMM=gdm-x-session"  produces a header, and then nothing, on both laptops.   I may be using LIGHTDM.  is there a corresponding command?


jiggling occurs on the Dell laptop only.   It does not occur when using the USB mouse.  It occurs with light finger pressure on the touch pad when trying to position the pointer over an edge of a window.

- movie attached
- evemu-record attached

Created attachment 1237227 [details]
xinput from hp laptop

Created attachment 1237228 [details]
xinput from dell laptop

Created attachment 1237229 [details]
jiggling movie (dell laptop)

mp4 movie taken from Samsung Galaxy S4 cellphone

Created attachment 1237230 [details]
evemu-record of jiggling

Maybe the jiggling is a different problem?


The primary issue of:  not being able to reach the corners of the desktop using the touchpad, still exists on both machines.

Let's move the pointer jiggling to Bug 1410263 and only deal with the "can't reach edges" issue here.

I still need the Xorg.log from the journal, see comment 10. Are you sure you're using the libinput driver? xinput list-props "AlpsPS/2 ALPS GlidePoint" should tell you, the prefixes are the driver name. If so, it's weird because gdm uses libinput too, so if it works there that would indicate that something is wrong either in X, or in the the driver.


(In reply to John Ellson from comment #6)
> "consitently towards the negative x/y axis"  may be an artifact of my tests
> strokes always being from LR to TL.  I would have said something like
> "spontaneously centering"

that's what you saw the pointer do but any "centering" should show up in the output. Since it's a jump from the current position (which should be top-left of center given your first movement) to the center and thus should show up with positive x/y coordinates. This doesn't happen though.


another random question: does it happen when you are just on battery power (i.e. not plugged in) or when plugged in with a mostly discharged battery? Sometimes we see these issues when the power supply is flaky.

What happens if you boot a non-rc kernel? Any changes?

Please do try GNOME on Wayland for comparison.

Created attachment 1237595 [details]
output of "journalctl -ef _COMM=gdm-x-session" from GDM+GNOME_on_Xorg

[This may be a dup of comment sent by replying to email which hasn't shown up here yet...]

Finally found out how to switch-displaymanager back to GDM from LIGHTDM. The switching isn't done cleanly and requires a power-cycle before the new displaymanager shows up.

Anyway, the problem does seem to be related to X emulation over Wayland ...

On the HP laptop:

GDM is OK (can reach corners of screen using touchpad)
LIGHTDM is not

Logging in from GDM:

GNOME is OK (One assumes this is GNOME on Wayland, although nowhere does it indicate this.)
GNOME Classic is not
GNOME on Xorg is not
MATE is not

I'll attach the _COM=gdm=x-session from GNOME on Xorg

Results on the Dell laptop.

   GDM + GNOME is OK   (can reach edges of desktop using touchpad)

   GDM + GNOME on Xorg
   GDM + Mate
     
       both hang.    Lots of printk + nouveau messages  .. investigating further

(The results in #20 are for the non-rc kernel-4.9.0-1, apologies for not making that clear in the comments.)

Current status of Dell Laptop using latest available updates:

    kernel-4.10.0-0.rc2.git0.1.fc26.x86_64
    gdm-3.22.1-1.fc26.x86_64
    xorg-x11-server-Xwayland-1.19.0-3.fc26.x86_64
    mate-desktop-1.17.0-1.fc26.x86_64

GDM login screen is OK.  Can reach corners of login screen using touchpad.

GDM+Gnome  .... grey screen, pointer stuck at center,  doesn't move with touchpad or USB mouse, keyboard non-responsive.  Needed to power-cycle to recover

GDM+Mate.   Works OK with USB mouse.   Touchpad still doesn't reach edges of the desktop.  Pointer still jiggles when touchpad pressed (see Bug 1410263 )

ok, I'm think this may be caused by your touchpad being handled by the evdev driver now. sudo dnf install xorg-x11-drv-libinput and see if that fixes things.

alternatively, you can install xorg-x11-drv-synaptics-legacy, but that driver is on maintenance mode.

already installed:
  xorg-x11-drv-libinput-0.23.0-2.fc26.x86_64
  libinput-1.5.901-1.fc26.x86_64
  xorg-x11-drv-evdev-2.10.4.-1.fc26.x86.64

I was going to try removing one or the other, but that got compilcated:

  xorg-x11-drv-evdev is needed by mate-settings-daemon
  xorg-x11-drv-libinput is needed by cinnamon-desktop

Since Mate is the only desktop that is working for me at the moment, I went for
removing xorg-x11-drv-libinput, cinnamon-desktop, and multiple cinnamon bits

Removing libinput itself seems nearly impossible since everything seems to use it.

Anyway,  removing xorg-x11-drv-libinput had no effect:

    GDM ok
    GDM + Gnome hangs and requires power-cycle
    GDM + Mate works with USB mouse.  Touchpad can reach edges, and jiggles when pressed.

yeah, that requirement by cinnamon is bogus, and so is the mate-settings-daemon one IMO, but that's a different issue. Either way: you have some xorg.conf setup  that somehow overrides the libinput driver assignment with evdev. Probably
/usr/share/X11/xorg.conf.d/99-mate-evdev.conf (or in /etc). make sure evdev and xorg-x11-drv-libinput are installed, remove that config file and restart X. That should give priority to libinput again and fix the issue.

That helped the Dell Laptop.

    I removed the soft link:
         /etc/X11/xorg.conf.d/99-mate-evdev.conf
    (originally from: mate-settings-daemon)

    and the file it was linked to:
         /usr/share/X11/xorg.conf.d/10-mate-evdev.conf     (yes.  "99" -> "10")
    (originally from: xorg-x11-dev-evdev


Now the touchpad in Mate reaches the edges of the screen, and the jiggling is gone.

Gnome desktop still hangs with a grey screen, pointer in the center, and needs power-cycle to get out.

On the HP laptop, the same change fixed the issue of the mouse pointer not reaching the edges of the desktop in Mate,  but now the left-mouse-button does work to select (e.g.) the System menu.   Neither the button near the touchpad,  nor the button on the USB mouse works.

GDM+GNOME seems to be 100% functional on this laptop.

(In reply to John Ellson from comment #25)
> Gnome desktop still hangs with a grey screen, pointer in the center, and
> needs power-cycle to get out.

you mentioned a bunch of nouveau issues above, I'm going to assume that's the issue there. Please file a separate bug for that so the nouveau developers can look at it.

if GNOME works, then the issue is not in libinput, so I'm closing this bug. If MATE still has issues somewhere, I suggest filing a bug there so they can have a look at it. I recommend filing a new one and just linking to this one, it's hard to keep concentration across 26 comments, a clean slate can help with triaging :)

changing, this was indeed a synaptics bug. The changes I did to the xorg.conf sort order never got pushed && built (christmas got in the way) which explains why I thought it was done even though it wasn't. Sorry about that.


https://koji.fedoraproject.org/koji/taskinfo?taskID=17325419 is building now, that will make synaptics override libinput and work as intended