[Development] Fixing input for eglfs and friends

[Donald Carr]

Hey Jorgen,

I also like the idea of "default" plugins where eglfs will default to
loading support for the keyboard and an input device. I think having
some kind of heuristic for this will probably be gross, hacky and
harder to fathom than Girish's current approach which is baking it in.

There are 3 uses for eglfs:

1) First encounter. This is the first plugin everyone encounters.
(This will also probably suffice to ship a single purpose device for
many peoples needs). Most of these people will be running embedded
Linux.
2) Primary platform on X-less, Wayland-less systems like the Raspberry
Pi which has Qt 5 on the device out of the box and which actually
encourages people to play with Qt (as end users) from the command
line, like any hobbyist.
3) Reference code people will develop against. If these people can't
decouple the evdev plugin from the plugin, Charles Darwin himself will
contribute to the standing ovation.

Qt 5 is on the Pi, anyone who wants to run an application just has to
fire it up .............. after discovering it is developed against
Qt........... after learning about the oh-so-readable EvdevKeyboard
"generic plugin".

Girish/Johannes' work address' use case #1 and #2, at the cost of #3
which is great from my perspective since EGLFS is actually a shipping,
vitally important plugin which is gaining useful generally applicable
functionality at a healthy pace.

> I think evdev is excelent, but eglfs isn't linux specific.

Not on paper, but most people who hit it do so in an embedded Linux
context, <flamebait> at least until Hurd lands </flamebait>

> When we made
> eglfs it was intended as a platform which also could be copied and
> altered to fix special embedded deviceses needs. Moving all this logic
> into the plugins just so that we wont need to add -plugin at the command
> line seems the wrong direction to take.

There are certainly 2 separate sets of intentions. As Girish
indicated, it would be great if we could retain the "eglfs" name since
we are pushing this plugin heavily as being something usable, not a
minimal example. We could then create a minimal qpa example which was
more in keeping with the original bare bones EGLFS plugin. We will
happily do this for you.

> 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.

We have extended it; hence the push back. You mean non-upstream extending?

> Also what about the embedded devices that uses some other input api than
> evdev. Do we include code for them in eglfs?
>
> To solve the no -plugin problem, can't we do something like we do for
> the platform plugins, ie. have a define which can contain a "list" of
> plugins which should be loaded as default. Theres some interesting
> semantics to this, but that can be left to the guy that implements
> this to solve:)

Hah! I thought that is exactly what was happening.

Cheers,
Donald

-- 
-------------------------------
 °v°  Donald Carr
/(_)\ Vaguely Professional Penguin lover
 ^ ^

Cave canem, te necet lingendo
Chasing my own tail; hate to see me leave, love to watch me go