[Wayland-bugs] [Bug 103606] Is there any way to disable palm detection?

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103606

Peter Hutterer  changed:

   What|Removed |Added

 CC||peter.hutte...@who-t.net
 Status|NEW |NEEDINFO

--- Comment #1 from Peter Hutterer  ---
I need more info please

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 103606] Is there any way to disable palm detection?

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103606

--- Comment #2 from 90fve0+43ldlc5hx6...@sharklasers.com ---
I'm trying to find out how to disable palm detection as described here:

https://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html

While the palm exclusion zones behave as described in the documentation they
have an extremely high false positive rate for me. Thank you for your help.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 103210] One-finger tap registered as two-finger tap when touch-size-based palm rejection is triggered

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103210

--- Comment #12 from Peter Hutterer  ---
Ok, I have a reproducer for the crash in the form of a test case. Sequence of
events is:
* key event - starts dwt timeout
* touch down
* dwt timeout expiry
* touch changes to palm based on pressure/size

Cause is, I think, the dwt code that disables and re-enables tap so we miss out
on the TOUCH_BEGIN event while dwt is active and then crash when the assertion
is it because we're one behind. I'll fix this asap.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 103598] Mouse left to right inversion not working after upgrading from Fedora 24 to Fedora 26 !!

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103598

Peter Hutterer  changed:

   What|Removed |Added

 CC||peter.hutte...@who-t.net
 Resolution|--- |MOVED
 Status|NEW |RESOLVED

--- Comment #2 from Peter Hutterer  ---
currently handling this in the redhat bug linked above, please refrain from
commenting here to avoid having the information duplicated or distributed.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 776220] GTK applications crash when using touchscreen

[mutter]

https://bugzilla.gnome.org/show_bug.cgi?id=776220

Jonathan Briggs  changed:

   What|Removed |Added

 CC||zl...@acm.org

--- Comment #11 from Jonathan Briggs  ---
(In reply to Alexandre Franke from comment #10)

> Could you please give links to or quote those downstream reports? Merely
> stating they exist isn’t really helpful.

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 103210] One-finger tap registered as two-finger tap when touch-size-based palm rejection is triggered

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103210

--- Comment #15 from Peter Y. Chuang  ---
Thanks. I'm testing the newest patches, and I can confirm that it doesn't
crash. More testing may be needed to confirm that everything works, but my
early impression is that it behaves correctly in cases that used to cause
problems yesterday.

With regard to dwt, I'm somewhat reluctant to turn that off outright, because,
even with dwt on, there have been multiple instances where I accidentally moved
the cursor or click/tap something, causing me to lose a large chunk of text.
That being a real-world usage though means that it's somewhat difficult for me
to pinpoint what has gone wrong. It could have been accidental taps between dwt
timing-out and the next dwt initiation, or accidental click by the palm (as far
as I can tell, touch-size-based palm rejection does a good job in rejecting
palm movement and tap, but not if the palm presses on hard enough to trigger an
actual click). I will file a separate bug if I can figure out what goes wrong
there.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 103561] libinput 1.8.3 -> 1.9.1: laptop keyboard not working

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103561

--- Comment #13 from Stefano  ---
Hi there, yesterday try to work with git bisect to found where was introduced 
the regression: this is the result

/build/.../src/libinput >>> git bisect good
   ±[●●][1.8.901~32^2~1]
986604fd9d86e92a2f04499ca23970f440201349 is the first bad commit
commit 986604fd9d86e92a2f04499ca23970f440201349
Author: Peter Hutterer 
Date:   Fri Sep 1 17:30:08 2017 +1000

touchpad: if a device has a tablet mode switch, disable the touchpad

On some devices with a tablet mode switch, the touchpad is inacessible when
in tablet mode and we don't really need this except to avoid possible ghost
touches (none have been mentioned so far). On other devices like the Lenovo
Yoga, the touchpad points to the back of the device and it's hard to use
the
device without accidentally using the touchpad. For those, disabling the
touchpad is the best solution.

https://bugs.freedesktop.org/show_bug.cgi?id=102408

Signed-off-by: Peter Hutterer 

:04 04 64ff25308cc2946b68c7493fdd0448fe814e3168
a572cd4bded6a5ec42dafa53895237c4acbbe186 M  src
:04 04 b18982d161fa9e787f4971bb39258b5edd17a37b
d394dec756e183e20592e6ec4a831ae62f9a18e3 M  test
/build/.../src/libinput >>> 


During the process one commit introduce only the touchpad issue and keyboard
still working so the regression for keyboard is another commit after this.

Hope this help.

Edit: tested in an HP Pavillon Dv6 series.

Stefano Capitani
Manjaro Linux Team

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 103594] Touchpad works horrible

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103594

--- Comment #3 from Pavel  ---
Created attachment 135293
  --> https://bugs.freedesktop.org/attachment.cgi?id=135293=edit
evemu-record log

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 103210] One-finger tap registered as two-finger tap when touch-size-based palm rejection is triggered

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103210

--- Comment #13 from Peter Y. Chuang  ---
Created attachment 135279
  --> https://bugs.freedesktop.org/attachment.cgi?id=135279=edit
libinput-debug-events: tapping failure after typing

(In reply to Peter Hutterer from comment #11)
> (In reply to Peter Y. Chuang from comment #10)
> > 2. More of the times it doesn't work. In fact, taps don't work even well
> > after typing has ended *and* the palm is lifted. In this scenario,
> > tap-to-click doesn't recover until I type for a bit with my palm *off*.
> > After that, it works again after a tap or two, I think.
> 
> I really need something reproducible here or some pattern that we suspect.
> It's a bit tricky to write test cases otherwise. I suspect you're hitting
> one state where we don't recover correctly, but I don't quite know which one
> it is yet.
> 

This is one of the ways to trigger the problem:

1. Type something with palm off the touchpad
2. *Immediately* after the last keystroke, tap the touchpad repeatedly
3. Taps thereafter are ignored
4. It is sometimes possible for tapping to recover after a few more taps, so
perhaps dwt does time out correctly on some occasions. On some occasions
though, it is only possible if you hit a few keys then wait a bit and start
tapping again (see the attached log).

If I type with my palm(s) on the touchpad, taps are ignored almost all the time
after typing ends, and the tap doesn't have to happen immediately following the
last key stroke: I can stop typing and tap the touchpad a few seconds laster
and still get no response. And whether the palm is lifted or not doesn't seem
to matter. The only way to recover from it is to type something again with the
palm off, then wait a bit and start tapping.

Although I have encountered a few times that the touchpad responds correctly
after the last commit, the correct behaviour seems to happen only once
throughout one session. For instance, it works out alright the first time after
logging in (typing with palm on, then tapping after typing stops with one palm
still on), but after that it reverts to the behaviour above.

> > Regarding the typing-with-palm-off-then-palm-on scenario, I think it depends
> > on how quickly you put your palm on the touchpad after finishing typing. I'd
> > say tapping works if I put my palm on the touchpad about a second after the
> > typing has ended. But if the palm is put on the touchpad *immediately* after
> > the last keystroke, then tapping doesn't work.
> 
> There's a 500ms timeout (provided 2+ key presses) after the last key event.
> If you put your palm down within that timeout, it'll be detected as dwt
> palm. After those 500ms it'll be detected based on pressure/size/whatever. I
> definitely put my palm down within those 500ms, if you run libinput
> debug-events --verbose it'll print the type of palm detection triggered.

That makes sense from the perspective of providing dwt, though it may make
sense to recognise the tap in this scenario:

Typing with palm off -> Stop typing -> palm on within 500ms -> tap 1 second
after the last keystroke

I'm not sure if this can affect dwt though.

With regard to the crash, my observation is that it may be related to dwt too,
as you have discovered. One way to trigger it consistently is:

1. Type with palm off
2. *Immediately* put one palm on after stop typing

Another way is:

1. Type with one palm on
2. *Immediately* put another palm on after stop typing

The odd thing about the crash is that after a while without triggering any
crash, the above methods can't trigger crashes any more. So it always happens
in a fresh gnome-shell session, soon after logging in. This may be related to
the observation above regarding the correct behaviour happening only once in a
session.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 103606] Is there any way to disable palm detection?

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103606

--- Comment #3 from Peter Hutterer  ---
there's no toggle to turn those off (other than dwt). We generally try to focus
on fixing the issues that users have so it works without needing user-specific
configuration.

What version of libinput are you on, what laptop do you have, etc. See
https://wayland.freedesktop.org/libinput/doc/latest/reporting_bugs.html for a
list of what we'll probably need to debug this.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 103210] One-finger tap registered as two-finger tap when touch-size-based palm rejection is triggered

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103210

--- Comment #14 from Peter Hutterer  ---
The code lost track of the numbers of tapping fingers down which probably why
sometimes it couldn't be triggered except on the first run. I've put more
asserts in now to make sure that doesn't happen, and I fixed the tap
suspend/resume issue that triggered the crash. same github url as above.

Tapping always seems to recover after dwt, albeit only after the 500ms timeout.

On that note: a separate bug would be (for your touchpad) to disable dwt by
default. dwt is a kludge because we can't detect palms reliably enough but this
shouldn't be the case on your touchpad. Might be worth turning it off and
testing how well it behaves.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 103606] Is there any way to disable palm detection?

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103606

--- Comment #4 from 90fve0+43ldlc5hx6...@sharklasers.com ---
Sorry, I'll try to do a better job of explaining the issue.

By false positive I mean that I try to click or move the pointer but libinput
ignores it because the tap started in an exclusion zone. I find myself tapping
in an exclusion zone frequently. It is very frustrating to have my taps ignored
and to not be able to use the full area of my touchpad.

I did not include debugging information because according to
https://wayland.freedesktop.org/libinput/doc/latest/palm_detection.html this
behavior is intentional.

If it is not currently possible to disable palm detection then I suggest adding
the option to do so for people who prefer the reliability of being able to use
the entire touchpad over minimizing palm clicks.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs

[Wayland-bugs] [Bug 790031] New: GtkClipboardClearFunc is not being called

[gtk+]

https://bugzilla.gnome.org/show_bug.cgi?id=790031

Bug ID: 790031
   Summary: GtkClipboardClearFunc is not being called
Classification: Platform
   Product: gtk+
   Version: unspecified
OS: Linux
Status: NEW
  Severity: normal
  Priority: Normal
 Component: Backend: Wayland
  Assignee: gtk-b...@gtk.org
  Reporter: janku.jakub...@gmail.com
QA Contact: gtk-b...@gtk.org
CC: r...@robster.org.uk, wayland-bugs@lists.freedesktop.org
 GNOME version: ---

Created attachment 363167
  --> https://bugzilla.gnome.org/attachment.cgi?id=363167=edit
Testcase

GtkClipboardClearFunc supplied with gtk_clipboard_set_with_owner() or
gtk_clipboard_set_with_data() is not being called.

Likely related:
When using gtk_clipboard_set_with_owner(), gtk_clipboard_get_owner() returns
non-NULL value even though the clipboard is owned by another application.


Affects latest GTK+ from master (version 3.93), as well as stable version 3.22.
Concerns both GDK_SELECTION_CLIPBOARD and GDK_SELECTION_PRIMARY.

Testcase included.
Steps to reproduce:
1) click the "Set clipboard" button in the test program
2) copy (Ctrl+C) something from another application
3) return back to the test program

Actual results:
GtkClipboardClearFunc is not called at all.
gtk_clipboard_get_owner() returns the owner we set in step 1), although it
should return NULL, since the clipboard is owned by the app from step 2).

Expected results:
If the clipboard ownership is lost, GtkClipboardClearFunc should be called
subsequently (in this case in step 3)).
If the clipboard ownership has been claimed by another application,
gtk_clipboard_get_owner() should return NULL.

The behavior should correspond to the one on X11.


Build 2017-11-07 on Fedora 26

-- 
You are receiving this mail because:
You are on the CC list for the bug.___
wayland-bugs mailing list
wayland-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-bugs