You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ofAppEGLWindow: No keyboard support for non-x11 windows #1
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.
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
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.
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."
@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?
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:
@arturochttps://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).
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."
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'
—
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."
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!
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.
Activity
bakercp commentedon Nov 21, 2012
Keyboard example
e.g. https://github.com/chriscamacho/gles2framework/blob/master/src/input.c
Merge pull request #1 from arturoc/gles2
danzeeeman commentedon Dec 17, 2012
is this still an issue?
bakercp commentedon Dec 17, 2012
yes ... still working on it.
danzeeeman commentedon Dec 17, 2012
cool. I was looking at the milestones and this is the last one for 0.1. You need some help?
bakercp commentedon Dec 17, 2012
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 commentedon Dec 17, 2012
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 commentedon Dec 17, 2012
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 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 commentedon Dec 17, 2012
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 commentedon Dec 19, 2012
... very close on this.
bakercp commentedon Dec 19, 2012
@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
ofFileto stop blocking on the mouse read. I'd prefer to use yourofFileapproach for both. But since we are using that non-blocking C-style read inofSerial, I figured it wouldn't be too bad. Any thoughts on non-blocking asynchronous reads withfstream/ofFile?arturoc commentedon Dec 19, 2012
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:
bakercp commentedon Dec 19, 2012
I tried
readsomebut I believe it was blocking as well. I'll give it another try.danzeeeman commentedon Dec 20, 2012
do you have this on a branch?
On Wed, Dec 19, 2012 at 10:15 AM, Christopher Baker <
notifications@github.com> wrote:
"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 commentedon Dec 20, 2012
I will in about 30 minutes.
danzeeeman commentedon Dec 20, 2012
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
"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 commentedon Dec 20, 2012
very cool.
bakercp commentedon Dec 20, 2012
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 commentedon Dec 20, 2012
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.ofAppEGLNativeWindowandofAppEGLX11Window.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.
Merge pull request #1 from arturoc/3dprimitives