Bypass events and get the physical keyboard state directly

[Pekka Paalanen]

(I think you just sent an encrypted email to a mailing list. I assume
this was an accident, since nothing indicates otherwise.)


On Mon, 20 Feb 2017 21:56:03 +1300
Bryan Baldwin <bryan at katofiad.co.nz> wrote:

> I don't know why you mentioned Wayland. As a reference point? I'm not
> presently developing with a Wayland target.

Yes, as a reference point.

> I cannot track the state of the keyboard with the events I received,
> because, as described, they are garbage. Something between evdev and
> my code screws the input data. X11, GNOME, or SDL2. Out of that
> stack, X11 would have been my goto to look for a way to view input
> more directly, which is why I asked about your interfaces here, but
> even that was completely wrong.

There is probably a reason why something somewhere converts repeats
into up/down pairs, if that is the only problem you have. You could try
finding out which component is responsible for it, and ask on the
appropriate mailing list why it is so and how to work around it.

I would also hazard a guess that these up/down pairs come really close
to each other, so if you actually drained the event queue before
looking at the tracked keyboard state, maybe it would be what you need.
But that is just speculation from me.

FWIW, Wayland does not have repeat events itself. A toolkit may
manufacture those any way it wants based on keyboard state (the exact
state you seem to be wanting in the first place).

> Initial code tests I've made directly against evdev prove that the
> input seen is accurate and properly reported. Grabbing all the input
> devices is easy. Releasing and reacquiring all of them based on
> window focus is easy. Identifying what each device is and which to
> use is easy. I have no idea what you are talking about with Re: to
> permissions and security. I'm not sure where in the original software
> stack the input code is being ruined, but to whomever code that
> belongs, if you cannot deliver accurate input from the kernel with
> 100% confidence, you cannot be trusted to decide permissions or
> security, either.

I'm not convinced, but I won't argue about the easyness.

The security/permissions problem is this: if you are allowed to open
the input devices, you can also trivially implement an invisible
keylogger, just "forget" to close the devices. Obviously people don't
like that idea, hence in a usual system the input device permissions
are restricted, probably as far as to the root user. Hence your game
needs to run as root, or ask the user to bypass the set permissions
e.g. by adding himself to the 'input' group (which now opens the door
for keyloggers). Display servers often use logind DBus API to open input
devices to avoid running as root, but I believe logind would refuse
your game if a display server was also active at the same time.


Thanks,
pq


> On 02/20/2017 09:20 PM, Pekka Paalanen wrote:
> > On Mon, 20 Feb 2017 12:37:36 +1300
> > Bryan Baldwin <bryan at katofiad.co.nz> wrote:
> >  
> >> Okay, so further investigation has lead me to test code against
> >> evdev directly. Nevermind ;)  
> > But if you run under any kind of display server (windowing system),
> > that won't usually work at all, or works wrong.
> >
> > That is also why any kind of "bypass the display server" will not
> > generally work. There is a myriad of reasons for that, including
> > permission and security issues, even starting from how to even pick
> > the right devices.
> >
> > You really are expected to keep the keyboard state tracked in your
> > app, based on the events. Even evdev works like that. If you were
> > writing for Wayland, there would be libxkbcommon to do that, and I
> > believe SDL2 already uses libxkbcommon anyway (on Wayland).
> >
> > OTOH, if you were not running under any display server, then you'd
> > be fine with that approach.
> >
> > Your question would be better directed at SDL or the specific window
> > system fora (e.g. mailing lists).
> >
> >
> > Thanks,
> > pq  
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20170220/0cff5c2d/attachment.sig>