[Development] Fixing input for eglfs and friends

[Jørgen Lind]

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