| Age | Commit message (Collapse) | Author |
|---|
|
so we don't have to keep adding unsupporting ones to the preprocessors
in llvoiceclient.
Note that CM_WEBRTC is complementary to LL_WEBRTC, which means its
purpose is not to be XOR-ed.
Any WebRTC supporting (either using LL's or CM's build) will have
LL_WEBRTC set to ON, but *only* ones that use CM builds will have
CM_WEBRTC set to ON *too*.
|
|
|
|
The Debian version supported is 13 (trixie), because that's the version
I could install on my M1, hence the Boost default version is 1.83 & we
can use system's OpenJPEG 2.5.3.
Somehow CMake's FindOpenGL wasn't effective, but we can get around this
by setting the GL libraries paths when running cmake.
Debian aarch64 suffers from the same problem Fedora aarch64 had when
compiling libcurl, and it's assumed that it's Linux aarch64 thing.
When trying to build ColladaDOM when building the viewer, it couldn't
find Boost somehow, so building ColladaDOM is done in configuration
stage instead.
Upstream Variables.cmake is full of assumptions regarding architecture,
and ARCH is used in many places already for Debian/Ubuntu, so we have to
make sure ARCH is set with the correct value at the root level.
Pipewire on trixie is also too new, so it's cancelled here.
Some dependencies have the t64 suffixes on them, just like the currently
supported Ubuntu (because I guess 24.04 *is*, based on trixie).
The executable still crashes when launched on my M1, however, but we'll
commit the progress so far for now.
|
|
This reverts commit ced2d634a76561d231e2c5854721c643ac071916.
Turns out the original string is depended on by in-world creations,
specifically HUDs, to determine whether the media is viewed from
within SL or not.
Thank you Jenni Windrider for pointing this out.
|
|
Make some widgets less opaque for more consistency
|
|
almost forgot!
|
|
add cmake and patch to tumbleweed build instructions
|
|
This commit changes the look of the avatar cloud
|
|
for now, and if we do have to use SDL for Windows ARM64.
|
|
This is cherry-picked from an old commit which was reverted before, but
modified so that it only affects the platform that has to use system
libcurl 8 (only Windows ARM64 so far).
System libcurl, which is typically newer, doesn't accept when SL server
responses with an invalid Content-Encoding value (usually some value
that's probably meant to be put as the Content-Type value), that we'd
get "unrecognized or bad HTTP Content or Transfer-Encoding"
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding
A way to fix this would be to just not expect decompressed contents, by
letting libcurl have the default value for CURLOPT_ACCEPT_ENCODING, which
is NULL.
|
|
|
|
Only greying out the detach option on the contextual menu popped up by
right clicking the attachment in the 3D view/world, and not yet
preventing detachment from the inventory/wearing panels.
|
|
in commit b54464a34c3f441d40977e872df53825c7df4959
|
|
This reverts commit 6d9bda960f179aa8ea3765c10aa3140d22c74086, and
add the aarch64 condition for preloading.
We can't use gDirUtilp->getLLPluginDir() yet in llappviewerlinux because
it's not instantiated yet in that phase.
|
|
|
|
WARNING #Plugin# llplugin/llplugininstance.cpp(106) LLPluginInstance::load:
apr_dso_load of /usr/lib64/libmedia_plugin_cef.so failed with error 20019,
additional info string:
/usr/lib64/libcef.so: cannot allocate memory in static TLS block
https://github.com/chromiumembedded/cef/issues/3616
https://github.com/chromiumembedded/cef/issues/3803
https://magpcss.org/ceforum/viewtopic.php?t=19622
I tried adding mProcessParams.envs.add("LD_PRELOAD=/usr/lib64/libcef.so");
to indra/llplugin/llpluginprocessparent.cpp, it didn't get rid of the
error, but running `LD_PRELOAD=/usr/lib64/libcef.so megapahit` OR
`LD_PRELOAD=/usr/lib64/libmedia_plugin_cef.so megapahit` does.
It still doesn't load web pages, however, even though there are
process plugin activities.
|
|
Accidentally git added a line that wasn't meant to be staged yet.
|
|
|
|
|
|
Hides the Stand up button too, but doesn't prevent teleporting yet.
|
|
Untested cause I couldn't find any force ground sit command on the
attachment I got access to.
|
|
plus reorder header inclusions alphabetically.
|
|
|
|
|
|
|
|
and avoid viewer/project name hardcoding.
|
|
https://megapahit.com/show_bug.cgi?id=108
|
|
This would be for joysticks & spacemouses, which aren't that urgent.
This is disabled as it seems to be causing a segmentation fault on
Windows ARM64.
|
|
https://stackoverflow.com/questions/60588765/how-to-get-cpu-brand-information-in-arm64
|
|
This reverts commit 32871ee579bfbd4828f7888550897f619fdfd9d7.
|
|
This reverts commit 98e99812072e6125411174236e1421d9312a50da.
|
|
This reverts commit aac750c57fbd22814958a112d6c262254243130f.
|
|
|
|
Move semicolons for improved readability. (Sorry!)
|
|
Put ".tar.gz" and "/Downloads" in code blocks for increased visibility.
|
|
Update build instructions for distributions that require fmod in order for CEF to work, optionally include instructions for building with openal anyway.
|
|
working CEF"
(I messed up the hyperlinks lol)
|
|
Add notes about where to get fmodstudio, and optionally how to build with openal instead.
|
|
|
|
|
|
|
|
Release/2025.04.01
|
|
|
|
This time for installation/packaging.
|
|
|
|
Referred from cpuinfo.
|
|
until we are ready to enable media plugins on Windows ARM64.
|
|
Referred from cpuinfo.
|
|
|
|
LLQuad is a typedef of __m128, which is already translated by
sse2neon to float32x4_t (I thought sse2neon wasn't taking effect
and I tried just replacing __m128 with float32x4_t to see that it
didn't make a difference), but then I searched using the keyword
float32x4_t this time and found that others have had a similar
problem:
https://developercommunity.visualstudio.com/t/static-initialization-arm64-neon-datatypes/1238406
https://stackoverflow.com/questions/54016821/error-c2078-when-initializing-uint32x4-t-on-arm
https://github.com/kcat/openal-soft/issues/494
Looking at the type definition, on arm64 it can be initialised
using a designator, the member with the float type and 4 array
elements.
I know it's an MSVC (arm64) problem, but since MSVC is also used
on x64 and only Windows arm64 is suffering from this one in our
case anyway (we only support Windows arm64 building using MSVC so
far), it's just simpler to use the _M_ARM64 preprocessor instead
of _MSC_VER.
|
