Ticket #12081 (closed defect: fixed)

Opened 2 years ago

Last modified 23 months ago

Touchscreen can start dragging an item with the mouse finishing

Reported by: greenfeld Owned by: dsd
Priority: high Milestone: 13.1.0
Component: x window system Version: Development build as of this date
Keywords: Cc: garnacho, pgf
Action Needed: diagnose Verified: no
Deployments affected: Blocked By:
Blocking:

Description

  1. Install 13.1.0 os1 on a XO-1.75 with touchscreen.
  2. At Sugar's main activity screen, select an item with your finger but do not let go. Instead, attempt to drag the item using your finger away from Sugar's ring/wheel of activities.
  3. The mouse's item selection cursor may or may not appear where your finger started the stroke. Remove your finger from the screen and the mouse cursor may also move to where your finger left the screen but not show anything unusual. (This does not always happen.)
  4. Using the touchpad attempt to move the mouse cursor. The mouse cursor may jump back to where it was (or stay where the finger left it) but still be dragging the item you selected from Sugar's activity wheel.
  5. Click using the touchpad's primary button away from Sugar's activity wheel to clear the dragging action.

Attachments

favoritesview.py (24.1 kB) - added by erikos 2 years ago.
remove dnd support from Home View

Change History

  Changed 2 years ago by greenfeld

  • priority changed from normal to high

Attempting to then mouseover other Sugar activity icons using the touchpad causes them to be dragged as well.

It seems like the UI or touchscreen input gets stuck in dragging mode and then never gives it up, even if you switch to other Sugar screens, right click on things, etc. After this happens you cannot start any activity on Sugar's main screen using the mouse or touchpad.

  Changed 2 years ago by godiard

This problem affect the home, but also other activities using touch/touchpad, like Paint.

After using the finger in the screen, the effect is like if a button in the touchpad is pressed.

  Changed 2 years ago by dsd

  • cc garnacho added
  • owner changed from jnettlet to erikos

This is one for Carlos G - Simon will coordinate with him about the prioritisation in relation to other work.

See also #11901 - we should make sure that kbdshim is not interfering.

  Changed 2 years ago by dsd

  • milestone set to 13.1.0

  Changed 2 years ago by godiard

Another effect is when in this "sticky" mode, is very difficult use the palettes.

Changed 2 years ago by erikos

remove dnd support from Home View

  Changed 2 years ago by erikos

So the issue, as Gonzalo describes it correctly, does not only happen in the Home View. For example in Paint when in 'sticky mode' you are always drawing when moving the mouse cursor without pressing any button. So seems like somewhere in the stack a component does constantly fire off a button-press event.

If you remove dnd support from the Home View this View gets a bit more usable, but the real issue is somewhere lower in the stack.

  Changed 2 years ago by erikos

  • cc pgf added

I had a look at the package differences in regards to olpc-kbdshim in the 12.1.0 and 13.1.0 build.

In 12.1.0 we have a more recent version (olpc-kbdshim-27) than in 13.1.0 (olpc-kbdshim-26-3), this does probably explain as well that screen rotation is not working anymore see 27 release notes.

I tried to install the F17 package on 13.1.0 but had a missing dep on libudev. Looking at the udev version, I could only find (libgudev1-188-3.fc18.armv7hl) in 13.1.0, no udev needed in F18 anymore?

Sidenote: I wondered as well where from version 27 had been released? Is that the current repo?

  Changed 2 years ago by erikos

Ok, thanks to Peter I was able to test with olpc-kbdshim-27: the issue is still there (as well the 'can not rotate screen' issue is still present).

So the easiest way to reproduce this issue is:

- start the machine

- use the mouse/trackpad to open the paint activity

- do one stroke using the mouse/trackpad (you need to click and move)

- now touch the screen once

- do another stroke using the mouse/trackpad (you only need to move now)

follow-up: ↓ 13   Changed 2 years ago by erikos

Talked to Jon about it: "My guess is that this is bad behaviour between the legacy support in our kernel driver and Xorg, the legacy support tries to make the touch events emulate a mouse input. We may need to resurrect my code that allows legacy support to be turned on and off by a sysfs flag".

follow-up: ↓ 11   Changed 2 years ago by pgf

does the problem occur without olpc-kbdshim running at all? (use "/bin/systemctl stop olpc-kbdshim-udev.service")

@erikos: yes, that is the correct repo

in reply to: ↑ 10   Changed 2 years ago by erikos

Replying to pgf:

does the problem occur without olpc-kbdshim running at all? (use "/bin/systemctl stop olpc-kbdshim-udev.service")

I did killall olpc-kbdshim-udev ("/bin/systemctl stop olpc-kbdshim-udev.service" could not find that service) and could still reproduce the issue, yes.

@erikos: yes, that is the correct repo

Ok, was just wondering since there was no 27 release I could see there.

  Changed 2 years ago by dsd

The correct way to stop kbdshim is: systemctl stop olpc-kbdshim.service

I'd recommend doing that before any more debugging of this ticket -- just to rule out an additional layer (not that we have any reason to suspect kbdshim).

in reply to: ↑ 9   Changed 2 years ago by dsd

Replying to erikos:

Talked to Jon about it: "My guess is that this is bad behaviour between the legacy support in our kernel driver and Xorg, the legacy support tries to make the touch events emulate a mouse input. We may need to resurrect my code that allows legacy support to be turned on and off by a sysfs flag".

The current shipped code already has that patch, so the code tries not to report legacy events. But I wonder if reporting BTN_TOUCH is really necessary and if omitting it might improve things.

  Changed 2 years ago by dsd

I commented out the BTN_TOUCH calls and now the UI doesn't respond to touches at all (but evtest does report them). So I guess it is needed, but that's not what I had gathered from Documentation/input/multi-touch-protocol.txt

  Changed 2 years ago by dsd

After correcting the event stream as detailed in the above documentation, it still doesn't work. Details here: https://bugs.freedesktop.org/show_bug.cgi?id=54614

  Changed 2 years ago by dsd

  • owner changed from erikos to dsd
  • status changed from new to assigned

  Changed 2 years ago by dsd

http://lists.x.org/archives/xorg-devel/2012-September/033595.html fixes the issue where the mouse button seems to be held down after touching the screen.

The input maintainer is on holiday for a week or two, so I'll temporarily put a forked RPM xorg-x11-server-1.13.0-3.fc18.olpc1 in place for the next build, leaving this ticket open until its upstreamed.

The multitouch issue (https://bugs.freedesktop.org/show_bug.cgi?id=54614) is probably still pending, but not as important as the pointer emulation fix.

Also pushed arm-3.0-wip b832bdbe57fe2ba54deeed009524c71c58ee806c kernel patch to closer meet the kernel multitouch protocol documentation.

  Changed 23 months ago by dsd

  • status changed from assigned to closed
  • resolution set to fixed

The xserver patch has been accepted by the input maintainer.

Note: See TracTickets for help on using tickets.