Opened 4 years ago

Closed 4 years ago

Last modified 4 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:


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 4 years ago by yawning

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

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

Edit: Correct the Arch module path.

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

comment:2 Changed 4 years ago by yawning lives under /usr/lib/[i386,x86_64]-linux-gnu/dri on Debian. Arch is the odd one out this time.

comment:3 Changed 4 years ago by yawning

Resolution: fixed
Status: newclosed

comment:4 Changed 4 years ago by yawning

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

write(2, "dlopen /usr/lib/xorg/modules/dri/ failed (tor-browser_en-US/Browser/TorBrowser/Tor/ version `GLIBCXX_3.4.22' not found (required by /usr/lib/\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.