Review Request 122558: [screenlocker] Also grab XInput2 devices

[Martin Gräßlin]

> On Feb. 13, 2015, 4:08 p.m., Xuetian Weng wrote:
> > For the event case, it is totally fine to process the event. One just need to parse xcb_ge_event_t to get the on-wire event. If xcb struct is still not generated correctly, struct in xlib can still be used.
> > 
> > https://github.com/qtproject/qtbase/blob/dev/src/plugins/platforms/xcb/qxcbconnection.cpp#L1771
> > https://github.com/qtproject/qtbase/blob/dev/src/plugins/platforms/xcb/qxcbconnection_xi2.cpp#L462

honestly I considered it too much a corner case to handle it. I know quite well that it would be possible by defining the structs, but that's exactly what I didn't want to do. Let's ensure is OK, convenience is a different topic ;-)


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122558/#review75994
-----------------------------------------------------------


On Feb. 13, 2015, 10:50 a.m., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122558/
> -----------------------------------------------------------
> 
> (Updated Feb. 13, 2015, 10:50 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 341469
>     https://bugs.kde.org/show_bug.cgi?id=341469
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> -------
> 
> With XInput2 it's possible that multiple pairs of keyboard and pointers
> are connected. As the lock screen only grabbed keyboard and pointer using
> the core protocol any additional input devices were still reporting
> input events to non-lockscreen windows creating the risk of interaction
> with the system and accidentially typing a password where it doesn't
> belong.
> 
> This change ensures that all additional master devices are also grabbed.
> Unfortunately there are no xcb bindings for xinput2 (considered
> experimental and thus not build on at least all debian based distros)
> and because of that the XLib library is used. This brings some problems
> as we cannot process the events (for that we would need xcb bindings,
> to get the events). To still be able to get any keyboard and mouse events
> we grab using the core protocol as it used to be and then ignore the
> "Virtual core" devices and don't grab them with XInput2. Input events
> from additional devices are grabbed and ignored, but definately no longer
> delivered to other windows.
> 
> BUG: 341469
> FIXED-IN: 5.3.0
> 
> 
> Diffs
> -----
> 
>   ksmserver/screenlocker/ksldapp.cpp e23b50fbcaac659bb6ef1b36a4de6efc63573978 
>   ksmserver/screenlocker/ksldapp.h 7a32fb11486ecd97fc022a2ce97e820b90f31394 
>   CMakeLists.txt dc5e7a050b47cbf61f654f2a28e265c69cb53c26 
>   config-X11.h.cmake ee5183a6329aac3120675766ff8a336055c07e9b 
>   ksmserver/screenlocker/CMakeLists.txt 12c1603a89af25182cde771775f5dec35494a7e5 
> 
> Diff: https://git.reviewboard.kde.org/r/122558/diff/
> 
> 
> Testing
> -------
> 
> Use "xinput create-master foo" and "xinput reattach" to create a second pair of input devices. Test that without the change the second keyboard prints to a konsole while the screen is locked, verified with the change that the input events are no longer going to the konsole
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150213/ac508f45/attachment-0001.html>