<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Yup, the encryption was an automagickal
client mistake.<br>
<br>
And I understand all your points, and don't disagree with the
security model. I just don't think that the people and the
software that are assuming responsibility for system security
should be. I'm not afraid to go and look, then tear it up and
write my own thing if its a good use of time. I think its going to
be a very good use of time these days ;)<br>
<br>
For posterity, the input problem I had is a bug in SDL2. Pressing
and holding down a key was not producing events with the repeat
flag set. It produced pairs of keydown & pressed - keyup &
released events without the repeat flag set. These events
continued to be send long after the key was physically released.
It is an untenable expectation for the application to track key
state with garbage input.<br>
<br>
This is a known SDL2 bug affecting at least verisons 2.0.4<br>
<a class="moz-txt-link-freetext" href="https://bugzilla.libsdl.org/show_bug.cgi?id=3472">https://bugzilla.libsdl.org/show_bug.cgi?id=3472</a> and 2.0.5.<br>
<br>
There is a patch I've tested locally on my own system, and it
works.<br>
<a class="moz-txt-link-freetext" href="https://bugzilla-attachments.libsdl.org/attachment.cgi?id=2594">https://bugzilla-attachments.libsdl.org/attachment.cgi?id=2594</a><br>
<br>
<br>
On 02/20/2017 11:17 PM, Pekka Paalanen wrote:<br>
</div>
<blockquote cite="mid:20170220121738.4d39bb69@eldfell" type="cite">
<pre wrap="">(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 <a class="moz-txt-link-rfc2396E" href="mailto:bryan@katofiad.co.nz"><bryan@katofiad.co.nz></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I don't know why you mentioned Wayland. As a reference point? I'm not
presently developing with a Wayland target.
</pre>
</blockquote>
<pre wrap="">
Yes, as a reference point.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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).
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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
</pre>
<blockquote type="cite">
<pre wrap="">On 02/20/2017 09:20 PM, Pekka Paalanen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Mon, 20 Feb 2017 12:37:36 +1300
Bryan Baldwin <a class="moz-txt-link-rfc2396E" href="mailto:bryan@katofiad.co.nz"><bryan@katofiad.co.nz></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Okay, so further investigation has lead me to test code against
evdev directly. Nevermind ;)
</pre>
</blockquote>
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<p><br>
</p>
<div class="moz-signature">-- <br>
<img src="cid:part1.2606284B.0981CF07@katofiad.co.nz" border="0"></div>
</body>
</html>