Support for null QWindow was added to handleKeyEvent() in qtbase about 3 weeks ago. Such calls were previously ignored which may explain the behavior you see.
On top of this, neither minimal nor eglfs will work properly with key events because QGuiApplication::focus/activeWindow() always returns null due to the lack of any QWindowSystemInterface::handleWindowActivated() or QPlatformWindow::requestActivateWindow() calls in these plugins. This is not actually an issue when the QWindow is made visible using showFullScreen() because for some reason this makes the window active without any additional steps from the platform plugin. This is however not something the plugins should count on and thus they need to be fixed. An upcoming patch will address this soon. Cheers, Laszlo On 10/14/2011 09:27 AM, ext Jeffrey Malone wrote: > Hi, > > Thanks for taking a look! > I agree that keeping it separate is indeed a much better solution, and > your concern about some not wanting udev/keyboard support is > definitely valid. > > Much of my investigation prior to integrating it into the eglfs plugin > was specifically at that goal of keeping the keyboard support > separate. > Unfortunately, while I did get the linuxinput plugin without too much > trouble to open the keyboard and start handling key events, my QWindow > would never receive them. > Setting a null pointer for the QWindow into > QWindowSystemInterface::handleKeyEvent() did not work, and > QGuiApplication::activeWindow() (and focusWindow()) consistently > returned null pointers. > > Ideally I would be able to keep it separate, and along with a bit of > cleanup, move the keyboard support entirely into the linuxinput > plugin. > Otherwise, the concerns about some not wanting keyboard support could > be addressed by using parameters passed to the eglfs plugin to enable > keyboard support and udev support. > > Thanks, > Jeffrey Malone > > On Thu, Oct 13, 2011 at 11:09 PM, Laszlo Agocs<[email protected]> > wrote: >> >> Hi Jeffrey, >> >> Perhaps it would be better to keep (restore) the keyboard support in the >> linuxinput generic plugin? That way platforms other than eglfs could >> potentially benefit too. >> >> Besides, keeping such driver-like solutions in a separate, optional >> generic plugin is always a good idea: what if some system uses eglfs >> without an actual keyboard? Initializing udev, keyvoard support, etc. is >> just a waste of time then. >> >> The target window shouldn't be a problem with eglfs: passing either 0 or >> QGuiApplication::activeWindow() to handleKey|Mouse|TouchEvent is enough. >> >> Regards, >> Laszlo >> >> On 10/14/2011 08:01 AM, ext Jeffrey Malone wrote: >>> Hey, >>> >>> I'm somewhat new to development on Qt itself, and am seeking >>> comments/suggestions for my attempts at getting basic Linux keyboard >>> support working with the eglfs platform plugin in Qt5. >>> My specific interests are in anyone pointing out any taboos I've >>> committed, especially changes that will need to be made before any >>> merge request is performed. >>> >>> I've setup a temporary repo with my modified plugin here: >>> https://gitorious.org/qt5-eglfs/qt5-eglfs >>> >>> A summary of what I've done: >>> >>> I took the generic linuxinput plugin removed in many commits ago that >>> included keyboard support for QWS and modified it to work without QWS >>> Screen and such. This involved moving the driver itself into the >>> eglfs platform plugin so I was able to control which QWindow to send >>> keyboard events to -- I researched extensively for a method of keeping >>> the two separate, but found nothing helpful. >>> >>> I've added two additional classes: >>> >>> QEglFSUDevMonitor >>> This class parses all connected devices via udev, and determines if >>> any are a keyboard. If they are, it emits a keyboardAdded(QString >>> &devnode) signal, with devnode being something like >>> "/dev/input/event2" >>> After the main event loop begins, it gets set to a monitor mode where >>> it watches udev for device added/removed messages. It then sends >>> additional keyboardAdded() and keyboardRemoved() signals out. >>> >>> QEglFSConnection >>> This class has an instance of QEglFSUDevMonitor, and handles its signals. >>> When a keyboard is added, it creates a QLinuxInputKeyboardHandler for >>> the device. >>> Whena keyboard is removed, it deletes the object. >>> >>> In QEglFSIntegration, a QEglsFSConnection is created. When the main >>> event loop is started, and a QWindow is created for the platform >>> plugin, it passes it to QEglFSConnection and starts their event-loop >>> based functionality (watching a socket via QSocketNotifier). >>> >>> >>> Presently, it supports hotplugging keyboards, and works well in my >>> limited testing. It lacks capslock support (which was noted in the >>> QWS keyboard implementation), which will need to be fixed, and it >>> fails to turn off console echo. >>> There are likely additional bugs, and if anyone notices them, I'd be >>> very interested to hear it :) >>> >>> Jeffrey Malone >>> _______________________________________________ >>> Qt5-feedback mailing list >>> [email protected] >>> http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback >> >> _______________________________________________ >> Qt5-feedback mailing list >> [email protected] >> http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback >> _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
