Keyboard integration for EGLFS platform plugin

Discussion:

Jeffrey Malone

2011-10-14 05:01:58 UTC

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

Laszlo Agocs

2011-10-14 06:09:23 UTC

Permalink

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

Post by Jeffrey Malone
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.
https://gitorious.org/qt5-eglfs/qt5-eglfs
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.
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
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

Jeffrey Malone

2011-10-14 06:27:37 UTC

Permalink

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

Post by Laszlo Agocs
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

_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

Laszlo Agocs

2011-10-14 13:26:35 UTC

Permalink

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

Post by Jeffrey Malone
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

_______________________________________________
Qt5-feedback mailing list
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback