|Summary:||www/otter-browser: tell user how to disable hardware acceleration|
|Product:||Ports & Packages||Reporter:||Lorenzo Salvadore <salvadore>|
|Component:||Individual Port(s)||Assignee:||freebsd-kde (Team) <kde>|
|Status:||Closed Works As Intended|
|Severity:||Affects Only Me||CC:||adridg, danfe, kde, salvadore, tcberner|
|Bug Depends on:|
Description Lorenzo Salvadore 2019-08-25 10:56:10 UTC
Created attachment 206890 [details] otter-browser --disable-gpu On older hardwares or systems where hardware acceleration has not been configured correctly the browser shows videos with wrong colors. This patch adds in pkg-message the suggestion to disable hardware acceleration through the --disable-gpu option. Testing is needed to verify that the option works. See bug #237277.
Comment 1 commit-hook 2019-08-25 16:28:59 UTC
A commit references this bug: Author: tcberner Date: Sun Aug 25 16:27:57 UTC 2019 New revision: 509803 URL: https://svnweb.freebsd.org/changeset/ports/509803 Log: www/otter-browser: add hint and resolution to color problems in video playback - when hardware accelartion is not available users can experience switched colors - to work around the issue it is possible to pass --disable-gpu to the command line PR: 240097 PR: 237277 Submitted by: Lorenzo Salvadore Reported by: Nuno Teixeira Changes: head/www/otter-browser/pkg-message
Comment 2 Tobias C. Berner 2019-08-25 16:31:18 UTC
Comment 3 Alexey Dokuchaev 2020-02-05 15:27:46 UTC
Looks like it no longer works: $ otter-browser --version Otter 1.0.81 $ otter-browser --disable-gpu Otter: Unknown option 'disable-gpu'.
Comment 4 Lorenzo Salvadore 2020-02-05 15:36:30 UTC
(In reply to Alexey Dokuchaev from comment #3) --disable-gpu still works for me on falkon so I think the issue is that otter-browser now requires you to add some special keyword to pass arguments for qt5-webengine. You can try "--qt-flag disable-gpu": this is what works on qutebrowser. Maybe it would have been better to open a new PR for the issue. If you want to open a new PR, feel free to CC me if you want. If you stay on this PR, then I think you should at least reopen it.
Comment 5 Alexey Dokuchaev 2020-02-08 07:36:18 UTC
(In reply to Lorenzo Salvadore from comment #4) > --disable-gpu still works for me on falkon so I think the > issue is that otter-browser now requires you to add some > special keyword to pass arguments for qt5-webengine. Looks like `www/falkon' happily accepts any option (tried with "falkon --nonexistent-foo-bar-42" :-) but for the record, I do have WebEngine backend selected in the ~/.config/otter/otter.conf: [Backends] Web=qtwebengine > You can try "--qt-flag disable-gpu": this is what works on > qutebrowser. It does not seem to work with Otter: $ otter-browser --qt-flag disable-gpu Otter: Unknown option 'qt-flag'. > Maybe it would have been better to open a new PR for the > issue. If you want to open a new PR, feel free to CC me if > you want. If you stay on this PR, then I think you should > at least reopen it. Initially I was not sure whether it appies to an earlier version and thus reopen would make sense, but now I see that the port was updated to current version (1.0.81) in the earlier PR bug #239203, so the problem I'm seeing is related to this PR and current version, reopening.
Comment 6 Lorenzo Salvadore 2020-02-09 08:56:00 UTC
(In reply to Alexey Dokuchaev from comment #5) Bug is earlier, you are right, but commit is later. The commit for this bug report has been processed in 2019-08-25, while the commit for otter's update in 2019-10-12. Thus most probably it is that last update that broke something. Moreover, that update was not a normal one: commit message says "The last official release was 1.0.01 in january 2019, way too long ago for a web browser. Many Linux distro's also offer weekly snapshots of this browser (often calling it 1.0.81). Instead, bump to a different fake release number; I'm concerned that 1.0.81 might be too high." and according to the Makefile the sources to build from are selected through a git commit: GH_TAGNAME= 22de58d. If we add to this that the most recent weekly snapshot (not the one in ports tree) is considered likely to have bugs (see https://sourceforge.net/projects/otter-browser/files/otter-browser-weekly300/ ), then we can expect that the verions in ports tree can have even more. I suggest to update otter to the very last weekly snapshot, then, if something is broken, report it upstream.
Comment 7 Lorenzo Salvadore 2020-02-09 09:07:56 UTC
However, I must also say that with falkon (an other web browser with the same problem) I needed to specify --disable-gpu, while now I tried to remove it and everything works fine. This might have many causes, but the fact that you cannot pass it to otter and that it has no effects on falkon could also be a hint that the --disable-gpu option for qt5-webengine does not exist anymore (there were qt5-webengine updates too since I proposed that solution). Thus it could be a good idea to verify that the option still exist.
Comment 8 commit-hook 2020-07-19 13:39:11 UTC
A commit references this bug: Author: adridg Date: Sun Jul 19 13:38:27 UTC 2020 New revision: 542576 URL: https://svnweb.freebsd.org/changeset/ports/542576 Log: Remove mention of a command-line-flag that doesn't work. There is a discussion of these flags in qutebrowser's bugtracker (not otter!), https://github.com/qutebrowser/qutebrowser/issues/2671 but the mechanism of "--qt-flag" is specific to qutebrowser: it isn't a general Qt thing. I can't find anywhere in otter-browser's source history where it has a --disable-gpu flag: that **is** a Qt thing, as documented at https://doc.qt.io/qt-5/qtwebengine-debugging.html However the application has to be able to pass that on to Qt (which otter apparently doesn't anymore, and neither does falkon). Overall the recommendation is to use environment variables to manage Chromium-inside-WebEngine, as documented by Qt, e.g. QTWEBENGINE_CHROMIUM_FLAGS="--disable-gpu" otter-browser PR: 237277 240097 Changes: head/www/otter-browser/pkg-message
Comment 9 Adriaan de Groot 2020-07-19 13:46:25 UTC
Closing, though I'm a bit stuck for which resolution is right. The pkg-message isn't a good place to put this kind of information, and there's decent documentation out there about the environment for managing these Chromium internals.