-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ofAppEGLWindow: No keyboard support for non-x11 windows #1
Comments
Keyboard example |
is this still an issue? |
yes ... still working on it. |
cool. I was looking at the milestones and this is the last one for 0.1. You need some help? |
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 On Mon, Dec 17, 2012 at 1:11 PM, arturo notifications@github.com wrote:
"I believe in science. Unlike mathematical theorems, scientific results I cannot prove that electrons exist, but I believe fervently in their -- Seth Lloyd: Quantum Mechanical Engineer, MIT /. |
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 |
... very close on this. |
@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 |
you should be able to use istream::readsome which reads only if there's On 12/19/2012 07:28 AM, Christopher Baker wrote:
|
I tried |
do you have this on a branch? On Wed, Dec 19, 2012 at 10:15 AM, Christopher Baker <
"I believe in science. Unlike mathematical theorems, scientific results I cannot prove that electrons exist, but I believe fervently in their -- Seth Lloyd: Quantum Mechanical Engineer, MIT /. |
I will in about 30 minutes. |
please do! I think I converted a lot of skeptics tonight that were like 'I On Wed, Dec 19, 2012 at 9:11 PM, Christopher Baker <notifications@github.com
"I believe in science. Unlike mathematical theorems, scientific results I cannot prove that electrons exist, but I believe fervently in their -- Seth Lloyd: Quantum Mechanical Engineer, MIT /. |
very cool. |
This issue is now fixed with: 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 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. |
of3dPrimitive: fix vboMesh rendering + make it optional and default
Currently ofAppEGLWindow window does not support keyboard input.
The text was updated successfully, but these errors were encountered: