[Development] Fixing input for eglfs and friends

[Laszlo Agocs]

Regarding the input plugins: Once you reach a certain level of 
complexity (that is, you need tighter integration between the input 
subsystems and graphics, need device-specific workarounds, need to 
support special embedded setups, etc.), you will find it easier and more 
productive to simply fork the evdev* plugin sources and bake it all into 
your own platform plug-in living outside qtbase. Alternatively 
out-of-tree generic plug-ins should work fine as well.

This does not mean the plugins like eglfs, kms, evdev*, etc. in qtbase 
will be left to rot. We just need to find the right balance. These 
should serve as easy to extend reference examples while being at the 
same time functional on a wide range of systems (but possibly with 
limitations and in some cases they may need some configuration via 
arcane command-line arguments).

Cheers,
Laszlo

On 05/24/2012 10:26 AM, ext Jørgen Lind wrote:
> On Wed, May 23, 2012 at 11:54:18PM -0700, ext Girish Ramakrishnan wrote:
>> Hi,
>>
>> On Wed, May 23, 2012 at 11:33 PM, Jørgen Lind<jorgen.lind at nokia.com>  wrote:
>>> I think we should focus on keeping eglfs as small as possible, but
>>> keeping the readability of the code, so that the entry level for "extending"
>>> eglfs will be low.
>>>
>> I think this is the first thing that needs to be discussed :-)
>>
>> We have Qt running a wide variety of embedded hardware. You can see
>> the important boards that we work with here -
>> http://qt-project.org/wiki/Category:Devices. There's still many boards
>> that we haven't listed like tegra2&  3, trimslice, cubovision,
>> sodevilles, snowball etc. (we are working on it)
>>
>> Many of the boards require eglfs. Adding wayland support on these
>> boxes is not for mortals and is thus not an option for the foreseeable
>> future on any of these boards.
>>
>> Many of the boards come with very specific rootfs/linux. It's hard to
>> install stuff on them. udev support is either there or not there. That
>> doesn't mean you cannot plug devices into them, you can. Just that
>> udev isn't compiled and installed on the bsp by default and it's a
>> non-trivial task to cross-compile all that stuff.
>>
>> With the above in mind: we are approaching eglfs as a proper qpa
>> plugin that needs to be productized for the embedded community. It
>> needs to work out of the box. With that in mind, I have added many
>> features to configure and eglfs. Specific to eglfs: I have added board
>> specific initialization hooks, added gl cursor support. Hardware
>> cursor support for the raspberry pi is on it's way which is going to
>> complicate eglfs further (the change is on my dashboard). We want
>> eglfs to be meaningful out of the box and not require us to provide
>> arcane arguments like -plugin EvdevKeyboard. And definitely not,
>> -plugin EvdevKeyboard:/dev/input/event0 in the absence of udev.
> Yes, I understand that having something that runs out of the box is
> nice. But there is an endless stream of features and optimisations that
> you will want to do which is device specific, as you have pointed out
> yourself.
>
> I fail to see how that is much different than having an out of QtBase
> plugin. This is part of what I tried to get across with the
> QtPlatformSupport discussions. Having plugins outside the QtBase source
> is intended. This is part of the reason why we moved the wayland plugin
> out of the QtBase source.
>
> <flamebait>
> Its sort of funny though. We have invested so much time and effort into
> making QPA, but then we managed to create a Qt4 like structure
> inside our plugin.
> </flamebait>
>
> Jørgen
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development