ofAppEGLWindow: No keyboard support for non-x11 windows

[bakercp]

Currently ofAppEGLWindow window does not support keyboard input.

[bakercp]

Keyboard example
e.g. https://github.com/chriscamacho/gles2framework/blob/master/src/input.c

[danzeeeman]

is this still an issue?

[bakercp]

yes ... still working on it.

[danzeeeman]

cool. I was looking at the milestones and this is the last one for 0.1. You need some help?

[bakercp]

It's mostly done. Right now I'm trying to solve the issue of how to deal with the fact that without a windowing system, we have no notion of "focus" when it comes to dealing with keyboard input. we essentially have a keylogger, so when (for instance) we launch an app all of the apps still get the keyboard input. Anyway, I think I have some solutions, and hope to put them up for testing in the next day or two.

[arturoc]

i think we shouldn't care about the focus too much, when using the non-x11 mode there's no window manager so we don't need to care about windows, we should suppose that there's only one app running. when there's an x11 manager then we just use the x11 version

all we need is a way to detect x11 or even just a switch so in main we can choose if we want to run in x11 or without window manager

[danzeeeman]

I'm with arturo as if I'm running this from SSH or setting it up to
Auto-boot into the App I want it to be the only thing getting the keyboard
presses.

On Mon, Dec 17, 2012 at 1:11 PM, arturo notifications@github.com wrote:

i think we shouldn't care about the focus too much, when using the non-x11
mode there's no window manager so we don't need to care about windows, we
should suppose that there's only one app running. when there's an x11
manager then we just use the x11 version

all we need is a way to detect x11 or even just a switch so in main we can
choose if we want to run in x11 or without window manager

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-11452848.

"I believe in science. Unlike mathematical theorems, scientific results
can't be proved. They can only be tested again and again, until only a fool
would not believe them.

I cannot prove that electrons exist, but I believe fervently in their
existence. And if you don't believe in them, I have a high voltage cattle
prod I'm willing to apply as an argument on their behalf. Electrons speak
for themselves."

-- Seth Lloyd: Quantum Mechanical Engineer, MIT

/.

[arturoc]

actually if you log through ssh you can also open an x11 window (if there's an x11 session running) doing:

export DISPLAY=0:0

and then starting the app

[bakercp]

... very close on this.

[bakercp]

@arturoc in order to keep mouse and keyboard polling in the same internal thread, I had to move back to a c-style non-blocking read as I wasn't able to get the fstream-based ofFile to stop blocking on the mouse read. I'd prefer to use your ofFile approach for both. But since we are using that non-blocking C-style read in ofSerial, I figured it wouldn't be too bad. Any thoughts on non-blocking asynchronous reads with fstream/ofFile?

[arturoc]

you should be able to use istream::readsome which reads only if there's
something available

On 12/19/2012 07:28 AM, Christopher Baker wrote:

@arturoc https://github.com/arturoc in order to keep mouse and
keyboard polling in the same internal thread, I had to move back to a
c-style non-blocking read as I wasn't able to get the fstream-based
|ofFile| to stop blocking on the mouse read. I'd prefer to use your
|ofFile| approach for both. But since we are using that non-blocking
C-style read in |ofSerial|, I figured it wouldn't be too bad. Any
thoughts on non-blocking asynchronous reads with |fstream/ofFile|?

—
Reply to this email directly or view it on GitHub
#1 (comment).

[bakercp]

I tried readsome but I believe it was blocking as well. I'll give it another try.

[danzeeeman]

do you have this on a branch?

On Wed, Dec 19, 2012 at 10:15 AM, Christopher Baker <
notifications@github.com> wrote:

I tried readsome but I believe it was blocking as well. I'll give it
another try.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-11533340.

"I believe in science. Unlike mathematical theorems, scientific results
can't be proved. They can only be tested again and again, until only a fool
would not believe them.

I cannot prove that electrons exist, but I believe fervently in their
existence. And if you don't believe in them, I have a high voltage cattle
prod I'm willing to apply as an argument on their behalf. Electrons speak
for themselves."

-- Seth Lloyd: Quantum Mechanical Engineer, MIT

/.

[bakercp]

I will in about 30 minutes.

[danzeeeman]

please do! I think I converted a lot of skeptics tonight that were like 'I
have 2 pi and I didn't know it was this far along! I'm gonna download the
branch tonight'

On Wed, Dec 19, 2012 at 9:11 PM, Christopher Baker <notifications@github.com

wrote:

I will in about 30 minutes.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-11557664.

"I believe in science. Unlike mathematical theorems, scientific results
can't be proved. They can only be tested again and again, until only a fool
would not believe them.

I cannot prove that electrons exist, but I believe fervently in their
existence. And if you don't believe in them, I have a high voltage cattle
prod I'm willing to apply as an argument on their behalf. Electrons speak
for themselves."

-- Seth Lloyd: Quantum Mechanical Engineer, MIT

/.

[bakercp]

very cool.

[bakercp]

This issue is now fixed with:

6166e7b
f06345b

With non x11 keyboards (and mouse now too), we read directly from the linux event system, which relies on USB devices. If no input devices (mouse/keyboard) are present, then nothing can be read. Currently, if a program starts without a mouse / keyboard connected, there can be no mouse/keyboard input without restarting, even if the keyboard is plugged in while the program is running.

I added a udev callback / polling loop that looks for attached usb devices. The plan is to set it up so that if no keyboard is attached (or if it becomes unplugged), that udev listener will manage the setup and teardown of keyboard and mouse devices behind the scenes so that all of that can happen while the program is still running. It's probably a few hours of work to get it working flawlessly -- a future goal!

[bakercp]

Also, keyboard mapping is still rudimentary. (Almost) all of the special OF special keys are explicitly mapped and other keys are looked up in a rudimentary linux event keycode->character lookup table.

There is probably a better way to do that ... but this works for the moment.

Finally, as I've continued adding these features, I'm once again wondering if it would make sense to refactor into a few subclasses of ofBaseAppEGLWindow, i.e. ofAppEGLNativeWindow and ofAppEGLX11Window.

In the near future, Raspberry Pi will be able to support both. Right now, it's hard-coded (ifdef'd) for RPI to not use x11. I haven't tested any of the x11 code on RPI, but it should work ... I think.