Created attachment 200712 [details] Safe-Mode-Disable-HA LibreOffice Bug Report: Hardware Acceleration Enabled by Default Causes Serious Usability Issues Summary LibreOffice's hardware acceleration setting defaults to ON, causing significant usability issues across both physical and virtual machines with no system-wide configuration option to disable it, even when properly installed with machine-wide scope. Please also read this: https://superuser.com/questions/1896695/ Component LibreOffice - UI (or Graphics if available as a separate component) Version LibreOffice 25.2.3.2 Operating System Microsoft Windows 11 Pro (Version 10.0.26100, Build 26100, 64-bit) Hardware This issue has been confirmed on multiple systems, both physical and virtual. The issue is consistent across all tested environments. Severity Major (affects usability for all users and increases support burden) Priority High Steps to Reproduce 1. Install LibreOffice using winget with machine-wide scope: `winget install LibreOffice --scope machine --source winget` 2. Log in as a new user on the workstation 3. Launch LibreOffice for the first time or attempt to open a LibreOffice document 4. Observe that NOTHING HAPPENS - no window appears, no application starts, no error message is displayed Actual Result When a user attempts to launch LibreOffice or open a LibreOffice document, NOTHING HAPPENS - the application completely fails to start with no error message or indication of what's wrong. The only solution is for each user to: 1. Know to launch LibreOffice in safe mode (which is not intuitive for regular users) 2. Disable hardware acceleration (OpenGL, OpenCL, Vulkan) in the safe mode dialog 3. Apply changes and restart the application Expected Result One of the following solutions is needed: 1. Hardware acceleration should be OFF by default until reliable detection is implemented 2. A system-wide configuration option should exist for administrators to disable it for all users 3. An installation flag (e.g., `--disable-hardware-acceleration`) should be provided for administrators Critical Issues That Need Addressing 1. Default Setting Is Problematic: Hardware acceleration should be OFF by default until the developers implement code that can reliably detect when it's not working and automatically disable it. It is completely unreasonable to burden users with running in safe-mode and manually disabling this feature when all they're trying to do is view a document. This causes unnecessary support calls that could be entirely avoided. 2. No System-Wide Configuration: When an administrator determines that hardware acceleration doesn't work and disables it, this change only applies to the administrator's profile. Each additional user who logs into the workstation thereafter must repeat the same unintuitive steps. There is no apparent way for an administrator to address this problem for all users, even though if it doesn't work for one user, it won't work for any other users on the same workstation. 3. Missing Installation Option: If the default setting cannot be changed, an installation flag or parameter should be provided to allow administrators to install LibreOffice for all users with hardware acceleration OFF by default. Additional Information I have tested multiple workstations (both physical and virtual), and hardware acceleration consistently causes issues across all of them. This represents a serious usability problem in multi-user environments like educational institutions and businesses where support staff are burdened with repeated calls for the same issue from different users. The most critical aspect of this bug is that the application completely fails to start with no error message or indication of what's wrong. Users have no way to know what the problem is or how to fix it without technical assistance. This is an unacceptable user experience and creates significant support overhead. The issue occurs even with a fresh, proper machine-wide installation using the recommended installation method (`winget install LibreOffice --scope machine --source winget`). Despite this being a machine-wide installation, the hardware acceleration setting is still managed on a per-user basis. The issue is especially prominent in environments with basic/remote display adapters, which are common in enterprise and virtual desktop infrastructure (VDI) deployments. In such environments, hardware acceleration often causes more problems than benefits but requires manual intervention for each user. Attachments [Attached: Screenshot of the safe mode dialog showing the hardware acceleration option that each user must disable] Impact on Support and User Experience This issue creates a poor first impression of LibreOffice for new users and significantly increases support costs for organizations deploying LibreOffice across multiple workstations. More critically, it renders the application completely unusable until technical support intervenes to help the user run in safe mode - something most typical users would not know how to do on their own.
This is probably bug 166122
LibreOffice urgently needs reliable detection to determine whether hardware acceleration is actually working. If it's not, LibreOffice should automatically disable it—without forcing end users to troubleshoot or navigate unintuitive settings. Until that detection is fully reliable, hardware acceleration should be disabled by default. Please make this change in the very next release. Additionally, when hardware acceleration prevents LibreOffice from launching, and an administrator disables it, that change should apply to all users on the machine, not just the admin account. If it fails for one user, it will fail for all. Forcing every user to repeat the same workaround is unacceptable. I cannot emphasize this enough: PLEASE DISABLE HARDWARE ACCELERATION BY DEFAULT IN THE NEXT RELEASE, AND ONLY RE-ENABLE IT BY DEFAULT ONCE RELIABLE AUTO-DETECTION IS IN PLACE. For more emphasize, see here: https://neartalk.com/thao/
(In reply to launchpad from comment #2) > LibreOffice urgently needs reliable detection to determine whether hardware > acceleration is actually working. If it's not, LibreOffice should > automatically disable it—without forcing end users to troubleshoot or > navigate unintuitive settings. > Actually already had very effective testing around support of Vulkan (and before that for OpenGL), now being done with Google chromium skia libs. With fall back to skia based raster framing. Or manual de-selection of the skia libs, for fallback to 'default' GDI+ based rendering libs--CPU only or with CPU controlled HA. Those skia lib releases, external to project, were updated from m116 to m130 for the 25.2.0 builds. And some as yet undetermined fact of the testing framework has slipped. It is a routine issue, and once fully identified would likely make it into the 25.2 branch in an incremental patch release. > Until that detection is fully reliable, hardware acceleration should be > disabled by default. Please make this change in the very next release. Well that won't happen. More to the point to identify what's changed in the skia skwindow call when Vulkan test for a non-denylisted device is run and fails. Also, the denylist for Virtual devices should be more robust, specifically VMWare VMSVGA or MS Hypervisor VM Bus Video Device should be deny listed. And there is the possibility the skia based software rendering is also degraded on marginally supported GPUs and vendor drivers. Too soon to be certain.
You may succeed with a script that applies the flag to the user profile. But we should rather fix the issue causing the trouble. Reliably testing a system for hardware compatibility sounds like a huge challenge to me. Ultimately no topic for UX.
This can be useful: https://wiki.documentfoundation.org/Deployment_and_Migration#Some_tricks_for_post_deployment_configuration Try the LibreOffice registry entry <item oor:path="/org.openoffice.Office.Common/VCL"><prop oor:name="UseSkia" oor:op="fuse"><value>false</value></prop></item>
Maybe, instead of setting the "UseSkia" to false I would rather set "ForceSkiaRaster" to true.
(In reply to Tomaz Vajngerl from comment #6) > Maybe, instead of setting the "UseSkia" to false I would rather set > "ForceSkiaRaster" to true. Yep! That would cover the problem issues of a default launch with testing for Vulkan/Metal vector graphics. Though we'd still be tied to chrome skia libs and its needed driver support for SkWindow/SkCanvas calls, so Deny listing mechanism and better sysadmin support for user profiles and VM instances still would need attention. And with fewer users testing/failing reporting issues with vector rendering, improvements there would stall. Also, for older CPU/GPU & driver sets, are there HA issues to consider for OpenCL? Or is concern with HA just with graphics rendering. Seems like OpenCL fall back has been pretty robust since implemented 10 years back.