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"
This patch series fixes this bug: http://lists.freedesktop.org/archives/wayland-devel/2013-October/011528.html
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.
Kristian, you seem to have pushed the grab fixes to master. Should they be on 1.3 as well?
(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.
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.