Maybe we should drop x11 from default DISTRO_FEATURES :)

Will resolve the memory consumption and image size.

Well the image size isn't much different, I was just surprised to see
libx11 being included even in core-image-minimal (because systemd -> dbus
-> libx11: "dbus.do_package" -> "libx11.do_packagedata"), but in the end
the difference in ext4 was only 2MB (61MB/63MB), caused by following 4
libx11-6 core2-64 1:1.6.8-r0.0
libxau6 core2-64 1:1.0.9-r0.15
libxcb1 core2-64 1.13.1-r0.15
libxdmcp6 core2-64 1:1.1.3-r0.15

so I guess embedded no longer have neither small ram nor small flash.

On Thu, Aug 15, 2019 at 6:20 PM Alexander Kanavin <>

> On Wed, 14 Aug 2019 at 18:42, Richard Purdie <
>> wrote:
>> I'm not sure I agree with this.
>> We are meant to work on embedded systems and 256MB should be enough to
>> let us bring up X under qemu.
>> I'm fine with some sdk/ptest images having more memory, that makes
>> sense but 256MB not allowing X under qemu seems rather poor.
> I poked a bit more at this. The main difference between vmware emulated
> hardware and std emulated hardware is that X uses the standard 2D
> framebuffer interface for the former, and the full 3D stack for the latter
> (via use of glamor:
> The 3D stack (mesa and friends) is what causes the memory usage to swell.
> It is possible to disable this behaviour and enforce framebuffer usage
> (see 'man modesetting'), and I have verified that the RAM usage drops to
> similar levels as vmware, but that is not the upstream default; they have
> more or less obsoleted 2D drivers and are defaulting to 3D rendering
> nowadays. I'd rather follow that.
> Alex
> --
> _______________________________________________
> Openembedded-core mailing list
Openembedded-core mailing list

Reply via email to