Hi Denys,

On Mon, 22 Nov 2021 13:26:07 -0500 "Denys Dmytriyenko" <de...@denix.org> wrote:
> On Sat, Nov 20, 2021 at 03:00:05PM -0500, Vivien Didelot wrote:
> > Hi Denys,
> > 
> > On Fri, 19 Nov 2021 22:02:11 -0500 "Denys Dmytriyenko" <de...@denix.org> 
> > wrote:
> > > On Fri, Nov 19, 2021 at 03:15:33PM -0500, Vivien Didelot wrote:
> > > > Some distros or image recipes may rely on the presence of the "screen"
> > > > machine feature to install graphical front-end applications.
> > > > 
> > > > The ti33x SoC has an integrated GPU but does not have a screen per-se,
> > > > thus having this feature in the SoC configuration may lead to unwanted
> > > > packages being built.
> > > > 
> > > > Comment the 'screen' feature and remove it from MACHINE_FEATURES.
> > > 
> > > Well, 'screen' also implies not just a built-in LCD, but also external 
> > > screens 
> > > connected over HDMI or DVI. There are even remnant MACHINE_GUI_CLASS 
> > > variables 
> > > set in machine configs for either "bigscreen" or "smallscreen", although 
> > > that 
> > > one is no longer used.
> > 
> > I understand what you're saying. The confusion comes from the fact that
> > some people think about the 'screen' feature as 'the machine has an LCD
> > _controller_ and/or graphic output port(s)', while others think of it as
> > 'the machine literally has a graphical display'.
> 
> It is as simple as whether the machine is headless or not.
> 
> 
> > IMHO the 'screen' and 'touchscreen' machine features are a software-agnostic
> > way to describe the usage of a physical graphical display on the end 
> > product;
> > 
> > the 'directfb', 'x11' and 'wayland' distro features are a subjective way
> > to configure the graphical software stack of choice;
> > 
> > and finally the 'gpu' machine feature describes the capability of hardware
> > accelerated graphical processing.
> 
> Well, 'gpu' is not an upstream MACHINE_FEATURE, as BSPs can define additional 
> ones for own use. It used to be 'sgx', but with the addition of Rogue RGX 
> graphics, got renamed to more generic 'gpu':
> https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=0d9910c1710d9d4b2dd986403824ae05b6289e63
> 
> BTW, a display output (screen) can be very different and independent from a 
> 3D 
> processing (gpu), hence those are 2 separate features.
> 
> 
> > As an example, a distro can configure the Qt stack and tweak images like 
> > this:
> > 
> >     DISTRO_FEATURES:append = " directfb"
> >     PACKAGECONFIG_DISTRO:pn-qtbase ?= " \
> >         ${@bb.utils.contains('MACHINE_FEATURES', 'gpu', 'eglfs', '', d)} \
> >         ${@bb.utils.contains('MACHINE_FEATURES', 'touchscreen', 'libinput 
> > tslib', '', d)} \
> >         "
> >     EXTRA_IMAGE_FEATURES ?= " \
> >         ${@bb.utils.contains('MACHINE_FEATURES', 'gpu', 'hwcodecs', '', d)} 
> > \
> >         ${@bb.utils.contains_any('MACHINE_FEATURES', 'screen touchscreen', 
> > 'splash', '', d)} \
> >         "
> > 
> > while a generic image recipe or local conf can tweak packages this:
> > 
> >     IMAGE_INSTALL:append = " ${@bb.utils.contains_any('MACHINE_FEATURES', 
> > 'screen touchscreen', 'qt-kiosk-browser', '', d)}"
> > 
> > The MACHINE_GUI_CLASS actually shares the same concern, it assumes the
> > presence of a built-in screen of subjective size, which is simply wrong
> > for machines with an optional graphical display.
> 
> MACHINE_GUI_CLASS was used more widely in the past, but these days it only 
> affects the size of the logo in kernel boot when linux.inc from meta-oe is 
> included, which again is not used in meta-ti:
> https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-kernel/linux/linux.inc#n19
> 
> 
> > > All TI platforms with am335x SoC do have screen outputs, but I do 
> > > understand 
> > > there could be headless platforms from other manufacturers with this SoC. 
> > > The 
> > > correct way would be to not completely remove "screen" MACHINE_FEATURE 
> > > from 
> > > the SoC include file, but rather move it to corresponding machine configs 
> > > that 
> > > use it - am335x-evm, beaglebone, etc.
> > 
> > I would say that the 'screen' feature definitely doesn't belong to the SoC
> > configuration, and it doesn't belong to the machine description neither:
> > 
> > even though I understand it can be handy for beginners, boards like Rpi
> > and BeagleBone can be used headless and thus removing the feature from the
> > local configuration to get rid of unwanted configs is likewise cumbersome.
> > 
> > I think it's the user responsibility to specify MACHINE_FEATURES += "screen"
> > in their local configuration to describe the usage of a graphical display,
> > especially for machines not shipped with a built-in one.
> 
> That's not how it works!
> 
> All available MACHINE_FEATURES are defined in machine config files. Think of 
> those as capabilities. The list defines what this specific machine is capable 
> of, but it's up to you to use it or not.
> 
> That's no different from the rest of them, such as:
> acpi, alsa, apm, ext2, ext3, vfat, screen, keyboard, touchscreen, pci, 
> pcmcia, 
> phone, serial, usbgadget, usbhost, bluetooth, wifi, x86, kernel26...
> 
> Note that some of them are really software capabilities, but historically 
> were specified in machine configs. And kernel26 has been dropped long ago, 
> but is still lingering in places...
> 
> A distro config, or an image recipe, or even end user via local.conf can 
> decide whether to act on those capabilities or not. E.g. It doesn't matter if 
> a machine can support 'alsa' audio if you don't need any audio in your image, 
> you simply do not install corresponding packages.
> 
> There are 2 very different approaches. 1) When you are building a reference 
> distro and try to be very flexible and do a lot of conditionals based on 
> capabilities and features. And 2) when you are making a final product for a 
> specific platform, where pretty much everything is predetermined and static.
> 
> So, if you are making a product, your image recipe should not rely on 
> checking 
> available capabilities or features that much, if at all...

Are you suggesting that one must write MACHINE_FEATURES:remove = "screen"
if their machine is headless (which is the case for a stock BeagleBone)?


Thanks,

        Vivien
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#14242): 
https://lists.yoctoproject.org/g/meta-ti/message/14242
Mute This Topic: https://lists.yoctoproject.org/mt/87177309/21656
Group Owner: meta-ti+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to