Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#20858 closed defect (fixed)

Make webgl work with forced software rendering.

Reported by: yawning Owned by: yawning
Priority: Medium Milestone:
Component: Archived/Tor Browser Sandbox Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The dynlib code totally breaks webGL. If the user chooses to enable this, it should be supported, through forced software rendering.

Child Tickets

Change History (4)

comment:1 Changed 3 years ago by yawning

Ok, I have this working, though finding swrast_dri.so is going to be annoying for the general case.

  • LIBGL_ALWAYS_SOFTWARE=1
  • Do the library enumeration thing for swrast_dri.so (Arch: /usr/lib/xorg/modules/dri, Fedora: /usr/lib64/dri, probably somewhere else on Debian because fuck you).
  • Put swrast_dri.so somewhere sensible.
  • LIBGL_DRIVERS_PATH=<somewhere sensible

Edit: Correct the Arch module path.

Last edited 3 years ago by yawning (previous) (diff)

comment:2 Changed 3 years ago by yawning

swrast_dri.so lives under /usr/lib/[i386,x86_64]-linux-gnu/dri on Debian. Arch is the odd one out this time.

comment:3 Changed 3 years ago by yawning

Resolution: fixed
Status: newclosed

comment:4 Changed 3 years ago by yawning

Because it was bothering me, I looked into the Arch Linux situation a bit more. libGL is failing to load swrast_dri.so because the libstdc++.so.6 shipped with Tor Browser is too old to satisfy libLLVM-3.9.so's dependency on my system.

write(2, "dlopen /usr/lib/xorg/modules/dri/swrast_dri.so failed (tor-browser_en-US/Browser/TorBrowser/Tor/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /usr/lib/libLLVM-3.9.so))\n", 201) = 201

Hardware rendering works fine, because the various hardware rendering DRI modules don't link against libLLVM. Nothing I can really do about this, at this point this is a Tor Browser bug more than anything else.

Note: See TracTickets for help on using tickets.