To prevent our whilelist from growing much more we know do an additional
sanity check via compiler builtin functions if we cannot detect all
mandatory CPU features via the cpu_features libray and if the CPU isn't
whitelisted. This should cover more or less all remaining cases unless
the compiler is unable to detect the features properly.
I also get the same SSE error on a virtual machine with an Intel Xeon Processor:
The CPU of your computer (Intel(R) Xeon(R) CPU E5520 @ 2.27GHz) does not support all
features Anbox requires.
It is missing support for the following features: SSE 4.1, SSE 4.2, SSSE 3
but checking /proc/cpuinfo reveals that it supports the features:
...
model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
...
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid pni ssse3 sse4_1 sse4_2 x2apic hypervisor lahf_lm pti
I hope adding the following code into the array in check_features.cpp could fix the problem:
// Intel Xeon Processor E5520
"E5520"
This commit uses GCC friendly pragmas to demote a clang error on
C99-specific feature usage to a warning.
The C99 feature that is used here is compound literals. It gets used
trough a macro from the dbus C library.
Remove a unused lambda capture on [this] in
anbox::cmds::CheckFeatures::CheckFeatures() and promote
-Wunused-lambda-capture back to error level on clang.
In some spare situations it might be useful to change the network
configuration of the bridge and with that also the configuration of
the Android container itself. We don't validate the configuration
and just apply it no matter if it ends up with network connectivity
in the container.
Not all CPUs can be detected with their correct feature set. For example
does cpu_features not work well enough when the support does not support
AVX (see https://github.com/google/cpu_features/issues/4). To mitigate
this we maintain a list of whitelisted CPU models.
It looks like that the Android system gets confused when both a pointer
and an touch based input device are connected to the system. As touch
support is so far only used Ubports we can keep it disabled for the
snap version but provide a configuration switch to enable it again.
