Bug 69778 - [bug] Multiple cursors appear when udev rules for seats are applied
Summary: [bug] Multiple cursors appear when udev rules for seats are applied
Status: VERIFIED FIXED
Alias: None
Product: Wayland
Classification: Unclassified
Component: weston (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-24 22:50 UTC by Brian Lovin
Modified: 2013-10-30 22:14 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Lovin 2013-09-24 22:50:25 UTC
Software Stack:
Fedora 19
3.10.10-200.fc19.x86_64
wayland (HEAD) 1.2.91-0-g4125367
drm (HEAD) libdrm-2.4.46-0-gc6d73cf
mesa (9.2) heads/9.2-0-g2cda3f0
libva (HEAD) libva-1.2.1-0-g88ed1eb
intel-driver (HEAD) 1.2.0-0-g6898ab7
weston (HEAD) 1.2.91-0-g7799385

If one configures udev rules (/etc/udev/rules.d/weston.rules) on a pointer device to use the seat functionality, then two pointers appear - one that is bound to the seat and one which is not bound to the seat.

To re-create:
1. Set up udev rules to assign a pointer device to a seat.
2. Unplug and replug pointer device (or otherwise apply the new udev rules)
3. Launch Weston, move the pointer and observe two pointers on the display.
4. Modify the udev rule by commenting the entire rule out, unplug/replug pointer device, now observe that the device controls the other pointer on the screen.

Here's an example weston.rules file, just modify ID_VENDOR_ID and ID_MODEL_ID for your device (use lsusb -vvv to find these values):
ENV{ID_VENDOR_ID}=="04d9",ENV{ID_MODEL_ID}=="0499",ENV{WL_SEAT}+="back0"
Comment 1 Jonas Ådahl 2013-10-17 21:05:29 UTC
This patch series fixes this bug: http://lists.freedesktop.org/archives/wayland-devel/2013-October/011528.html
Comment 2 Kristian Høgsberg 2013-10-21 21:14:24 UTC
I pushed Jonas' series, this issues should be fixed on master.  There's a new issues now, where we get a stuck move grab if we unplug while moving a window.  But the issue in this bug is fixed and on 1.3 now.
Comment 3 Jonas Ådahl 2013-10-29 09:36:48 UTC
Kristian, you seem to have pushed the grab fixes to master. Should they be on 1.3 as well?
Comment 4 Kristian Høgsberg 2013-10-30 16:17:37 UTC
(In reply to comment #3)
> Kristian, you seem to have pushed the grab fixes to master. Should they be
> on 1.3 as well?

Yeah, they should.  I was testing with an external touch screen and unplugging the touchscreen (just the usb input device, not the output) and even with your patches, the touch code has the same problem: plugging the touch screen back in doesn't work.  The problem seems to be that the num_tp is in weston_seat and doesn't get reset when you remove the last touch screen, but when I looked closer, it looks like we keep the weston_touch struct around event when we unplug the last touch device.

The weird thing is that moving num_tp to weston_touch did fix the problem, but I don't understand why, since it still doesn't get reset.  Anyway, your patches certainly improve status quo and are a requirement for fixing touch so I'll pick them over to 1.3.
Comment 5 Jonas Ådahl 2013-10-30 21:06:16 UTC
Hmm. Is it that it doesn't get reset because plugging it in doesn't call the init t(In reply to comment #4)
> (In reply to comment #3)
> > Kristian, you seem to have pushed the grab fixes to master. Should they be
> > on 1.3 as well?
> 
> Yeah, they should.  I was testing with an external touch screen and
> unplugging the touchscreen (just the usb input device, not the output) and
> even with your patches, the touch code has the same problem: plugging the
> touch screen back in doesn't work.  The problem seems to be that the num_tp
> is in weston_seat and doesn't get reset when you remove the last touch
> screen, but when I looked closer, it looks like we keep the weston_touch
> struct around event when we unplug the last touch device.

I left the struct deliberately to be able to keep some state. This might only make sense when using a pointer though, because it'll leave the cursor at the same position as when you unplugged. Probably need some reset function there, clearing some state while still keeping some intact. It seems the reason that it works already using a mouse is because the kernel will send button-up events upon unplugging, making button_count reach 0.

> 
> The weird thing is that moving num_tp to weston_touch did fix the problem,
> but I don't understand why, since it still doesn't get reset.  Anyway, your
> patches certainly improve status quo and are a requirement for fixing touch
> so I'll pick them over to 1.3.

That's odd. I can only imagine that it works because you'd receive touch-up evdev events when you unplug making num_tp end up at 0, but then it should work wherever you put the variable.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.