GNOME Bugzilla – Bug 733980
Touch events not forwarded properly to VMs
Last modified: 2018-01-11 10:10:20 UTC
I have a touch screen and input into a VM (both windowed and fullscreen) don't always activate the right things. For example a modal close dialog on fedora doesn't take input, input ends up on the close button instead. This behaviour is not 100% consistent, and isn't related to modal dialogues only ( also happens with Gnome-boxes inside gnome-boxes) Unfortunately I can't get a proper recording of the matter as the touch events arent registered properly into the recording.
Since no Boxes developer has a touchscreen, this would be "Patches please or won't happen in the near future at least" cases. :(
(In reply to comment #1) > Since no Boxes developer has a touchscreen, this would be "Patches please or > won't happen in the near future at least" cases. :( And hence closing this. Please do re-open with patches!
(In reply to comment #2) > (In reply to comment #1) > > Since no Boxes developer has a touchscreen, this would be "Patches please or > > won't happen in the near future at least" cases. :( > > And hence closing this. Please do re-open with patches! Can't we simulate touchscreens with the GtkInspector?
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Since no Boxes developer has a touchscreen, this would be "Patches please or > > > won't happen in the near future at least" cases. :( > > > > And hence closing this. Please do re-open with patches! > > Can't we simulate touchscreens with the GtkInspector? Sorry for late reply but for some reason I didn't see this before. I guess but can't be sure. If not, Mattias (who has hardware) has promised to help test/hack this during FOSDEM.
We have this on Spice TODO list for years. I just opened a bug, better than the wiki TODO page: https://bugs.freedesktop.org/show_bug.cgi?id=86524
(In reply to comment #5) > We have this on Spice TODO list for years. > > I just opened a bug, better than the wiki TODO page: > https://bugs.freedesktop.org/show_bug.cgi?id=86524 Thanks! I'm closing on Boxes side now. Please re-open if you think it will require some work on Boxes side too.
(In reply to comment #6) > Thanks! I'm closing on Boxes side now. Please re-open if you think it will > require some work on Boxes side too. Well, I can imagine it will require Boxes to add a usb touch device (unless it's done entirely in guest agent)
(In reply to comment #7) > (In reply to comment #6) > > > Thanks! I'm closing on Boxes side now. Please re-open if you think it will > > require some work on Boxes side too. > > Well, I can imagine it will require Boxes to add a usb touch device (unless > it's done entirely in guest agent) We already add a usb tablet (though I never understood or remember what its for): <input type='tablet' bus='usb'/>
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > > > Thanks! I'm closing on Boxes side now. Please re-open if you think it will > > > require some work on Boxes side too. > > > > Well, I can imagine it will require Boxes to add a usb touch device (unless > > it's done entirely in guest agent) > > We already add a usb tablet (though I never understood or remember what its > for): > > <input type='tablet' bus='usb'/> The table is for absolute pointer (a must for remote client, relative pointer is a pain) I don't know much about tablet vs touch, but they are different USB devices that are either tablet or touch class. So you'll surely need that if qemu has to emulate the USB touch device.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/30.