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<[email protected]> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
