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

Reply via email to