[Development] Fixing input for eglfs and friends

[Girish Ramakrishnan]

Hi Jorgen/Laszlo,

On Thu, May 24, 2012 at 12:26 AM, Jørgen Lind <jorgen.lind at nokia.com> 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>
>

I think that's a valid point :-) They are all inside qtbase because of
convenience. The build system wasn't and still isn't very friendly
when it comes to creating separate modules.

I sort of agree with you and Jorgen. For eglfs, I have to point out
that the code there doesn't work on most boards out there since mostly
all boards need specific graphics initialization. So, yes, it's an
example and one that didn't work for me in most places :-) I also
added a eglfs/x11 backend sometime back to test in my laptop with
mesa.

I don't mind creating a separate submodule to carry out the proper qpa
plugin work. Would you be OK with:
a. Giving us the eglfs plugin name :-) This is mostly for our
convenience. We spent quite sometime educating people to use eglfs
right from the Qt4 days.
b. I will create a eglexample plugin that is basically eglfs without
the complexity of hooks, cursors etc. It will load input plugins as it
does today
c. After 5.0, I will move eglfs into a separate repo like wayland..

Sounds ok to you guys ?

Girish