On Thu, Dec 03, 2015 at 02:55:22AM -0600, Keith Packard wrote: > Peter Hutterer <peter.hutte...@who-t.net> writes: > > > that's going to be fun to work out. raw events are delivered to the root > > window only so you don't really know which client they get delivered to. > > They're before the actual event in the pipe, and in some cases the event > > isn't delivered to the client (e.g. if a grab deactivates or activates). > > Short of folding the raw event into the DeviceEvent and then extracting it > > out just before event deliver, I'm not sure how to sensibly work around > > this. > > One could imagine re-ordering the event queue so that the non-raw event > is queued first, and then retaining state in the processing of that > event that the raw event processing code could go look at. Ick.
yeah, let's not do that :) > > Raw keyboard events were a mistake but we already had so many ways to write > > a keylogger that one more didn't seem to matter. If we're cutting off all > > avenues for keyboard sniffing and we're ok with breaking things (see > > synclient), maybe it's worth to to discard raw keyboard events altogether, > > possibly based on a ServerFlag. > > Ok, I hesitated to suggest such a thing, but if you think this is > reasonable, then I'll go ahead and make a suitable patch. the main problem is: I don't know what we'll break with this. I really don't know who uses raw keyboard events, or if anyone does. Cheers, Peter _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
