search

openFrameworks-RaspberryPi / openFrameworks

This repo has migrated into the openFramworks core! Please go to http://github.com/openFrameworks/openFrameworks for the latest!
http://github.com/openFrameworks/openFrameworks
Other
104 stars 11 forks source link

ofAppEGLWindow: No keyboard support for non-x11 windows #1

Closed bakercp closed 11 years ago

bakercp commented 11 years ago

Currently ofAppEGLWindow window does not support keyboard input.

bakercp commented 11 years ago

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

danzeeeman commented 11 years ago

is this still an issue?

bakercp commented 11 years ago

yes ... still working on it.

danzeeeman commented 11 years ago

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

bakercp commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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/openFrameworks-RaspberryPi/openFrameworks/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 commented 11 years ago

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 commented 11 years ago

... very close on this.

bakercp commented 11 years ago

@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 commented 11 years ago

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 https://github.com/openFrameworks-RaspberryPi/openFrameworks/issues/1#issuecomment-11519071.

bakercp commented 11 years ago

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

danzeeeman commented 11 years ago

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/openFrameworks-RaspberryPi/openFrameworks/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 commented 11 years ago

I will in about 30 minutes.

danzeeeman commented 11 years ago

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/openFrameworks-RaspberryPi/openFrameworks/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 commented 11 years ago

very cool.

bakercp commented 11 years ago

This issue is now fixed with:

6166e7b617621420dadf06b740f96084f1ecef35 f06345b930f62c5cf5a747227a1eb3352d8b186a

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 commented 11 years ago

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.