Dear Maintainer,
* What led up to the situation?
I upgraded liferea and liferea-data 1.15.2-1 → 1.15.3-1, along with a
bunch of other updates (e.g. libwebkit2gtk 2.40.5-1 → 2.42.0-1)
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
The liferea window is divided into 3 parts:
1) the list of all my feeds
2) the list of all news items in the selected feed
3) the content a news item
Usually, when selecting a news item in 2, it gets shown in 3.
Since the upgrade, window 3 remains gray and does not show.
E.g. in Debian News (http://www.debian.org/News/news) there is the
following news item
```
<item rdf:about="https://www.debian.org/News/2023/20230918">
<title>DebConf23 closes in Kochi and DebConf24 location announced</title>
<link>https://www.debian.org/News/2023/20230918</link>
<description>
Yesterday, Sunday 17 September 2023, the annual Debian Developers and
Contributors Conference came to a close.
</description>
<dc:date>2023-09-18</dc:date> </item>
```
And the test `Yesterday, Sunday `… should get shown.
For news feeds with attachement (e.g.
https://cppcast.com/episode/index.xml) the attachments still get shown
at the bottom of window 3 to be downloaded.
Regards,
Paul
Hi, Thanks for reporting issues you encounter. Agreed (I use liferea myself). It works for me. So, what could be different (non-default) in your environment? Paul
Dear maintainer, I am affected by the same error as the opener. If I start liferea by terminal I get following errors/messages by clicking on an message to show it in window 3: LANG=C && liferea sys:1: Warning: g_atomic_ref_count_dec: assertion 'old_value > 0' failed KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 469x199: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 469x199: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 469x199: Permission denied Failed to create EGL images for DMABufs with file descriptors -1, -1 and -1 sys:1: Warning: g_bytes_get_size: assertion 'bytes != NULL' failed sys:1: Warning: g_bytes_get_data: assertion 'bytes != NULL' failed sys:1: Warning: g_uri_is_valid: assertion 'uri_string != NULL' failed Maybe that help you to find the error. If it is important: I'm using an nvidia-card in the system with the proprietary driver. Kind regards Thorsten
Hi. Same error here. $ liferea eglExportDMABUFImageMESA failed eglExportDMABUFImageMESA failed eglExportDMABUFImageMESA failed sys:1: Warning: g_atomic_ref_count_dec: assertion 'old_value > 0' failed sys:1: Warning: g_uri_is_valid: assertion 'uri_string != NULL' failed I'm also using the nvidia proprietary driver (525.125.06-2). Window manager is Fluxbox. Downgrading liferea to the previous version doesn't fix the error though. I also tested downgrading all libwebkit2gtk related packages to version 2.40.5-1. After that the content window works again. ~Tim
Hi, I spotted upstream bug 1308 [1]. Does it help to set WEBKIT_DISABLE_DMABUF_RENDERER=1 before calling liferea? Paul [1] https://github.com/lwindolf/liferea/issues/1308
Hi, you got it! when I start liferea on the command line with WEBKIT_DISABLE_DMABUF_RENDERER=1 liferea then it works as expected.
Am Dienstag, dem 10.10.2023 um 20:55 +0200 schrieb Paul Gevers: Hello Paul, yes, indeed that helps. Kind regards Thorsten
Hi, I just spotted bug 1082139 [1], and bug 1039720. I assume the problem is fixed for some time already. Can this be confirmed? Paul https://bugs.debian.org/1082139
Hello Paul, unfortunately problem still exists. The browser window SEEMS to be empty but in reality it is not. If I try to copy the (not showing) text in it, by left-mouse-button pressed and drag, nothing will be highlighted but when I click with middle-mouse-button in an editor text will appear. I can't tell you if it was like this from the beginning.
Hi, Can you confirm that the "WEBKIT_DISABLE_DMABUF_RENDERER=1" solution still works for you? Now I think of it, maybe we could add it to /usr/share/applications/net.sourceforge.liferea.desktop Are you in the position to try and add it on the line that has Exec=liferea %U like so: Exec=WEBKIT_DISABLE_DMABUF_RENDERER=1 liferea %U ? According to some resources [1], you also need to comment out the next line (or set it to false). Paul [1] https://wiki.archlinux.org/title/Desktop_entries#Modify_environment_variables
Hello Paul, Am Sonntag, dem 08.06.2025 um 21:35 +0200 schrieb Paul Gevers: Yes, it still works on console "Exec=WEBKIT_DISABLE_DMABUF_RENDERER=1 liferea %U ### DBusActivatable=true" The liferea entry in xfce4 menu disappears, also with "Exec=WEBKIT_DISABLE_DMABUF_RENDERER=1 /usr/bin/liferea %U ### DBusActivatable=true" In both cases I see in menuLibre a message like this: "/usr/share/applications/net.sourceforge.liferea.desktop Exec Das Programm 'WEBKIT_DISABLE_DMABUF_RENDERER=1 /usr/bin/liferea %U' wurde im Pfad nicht gefunden" The program couldn't be found in path. Also if I set the whole command in single quotes or in backticks It doesn't seem to work this way. Kind regards Thorsten
Hi Thanks for trying. Maybe we can point the desktop file to a wrapper script that does the above. Paul
Hello Paul, maybe I've found a solution. If I use instead of "Exec=WEBKIT_DISABLE_DMABUF_RENDERER=1 liferea %U" "Exec=env WEBKIT_DISABLE_DMABUF_RENDERER=1 liferea %U" it works for me. Maybe for others also... Kind regards Thorsten Am Montag, dem 09.06.2025 um 09:47 +0200 schrieb Paul Gevers:
Hi, Reading bug 1082139 again I wonder, do you have the latest version of webkit2gtk installed? If yes, maybe we should reassign this bug to webkit2gtk as another instance where this goes wrong. For the webkit2gtk maintainers to investigate. I don't like adding this hack to bookworm. I'm not sure we need it for trixie. Paul
Hello Paul, Am Donnerstag, dem 12.06.2025 um 11:53 +0200 schrieb Paul Gevers: ii libwebkit2gtk-4.1-0:amd64 2.48.3-1 ii libwebkitgtk-6.0-4:amd64 2.48.3-1 That was and is the latest version in debian sid Ok, will you do so? It's not just liferea that is affected. rednotebook has the same problem, there it is the word-cloud that's not visible. Kind regards Thorsten
Hi Thorsten, hi webkitgtk maintainers, This issue seems to be about a reintroduction of bug 1082139 in trixie: DMABuf regression with the proprietary NVIDIA driver Wait, what? I thought you were on bookworm. And I intended to ask if this bug was fixed in bookworm. Now, maybe the bug is back (or was never fixed), but it's very relevant that you report this on trixie. Doing so now. Added that to the affects line. Paul
Hmmm, we specifically carry a patch to disable DMABUF with NVIDIA, can you try what happens with WEBKIT_DISABLE_DMABUF_RENDERER=1 ? (you can also try with WEBKIT_FORCE_DMABUF_RENDERER=1 to force using the DMABuf renderer, this should fail if the problem is really there) Berto
Hi Alberto, In the recent history of this bug Thorsten explicitly confirmed [1] that setting WEBKIT_DISABLE_DMABUF_RENDERER=1 prevents the bug (and in message 79 he explicitly says this applies to sid/trixie). Paul [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053199#59
Oh I see, sorry I missed the backlog before the bug was reassigned. The interesting thing is that we're carrying a downstream patch to disable the dmabuf rendered in NVIDIA cards so it shold not be necessary to set WEBKIT_DISABLE_DMABUF_RENDERER=1. If you run 'glxinfo', what's the value of the OpenGL vendor string? Berto
On Wed, 25 Jun 2025 13:43:19 +0200 Alberto Garcia <berto@igalia.com> wrote: [...] Vendor string an renderer string are as follow: Kind regards Thorsten
Then there's something odd going on. WEBKIT_DISABLE_DMABUF_RENDERER=1 prevents the bug but WebKit should already disable the DMABUF renderer automatically if you have an NVIDIA card (OpenGL vendor string containing the 'NVIDIA' word). So the check is somehow not working. If I prepare a modified build for trixie with additional debug messages would you be able to give it a try? Berto
Am Montag, dem 30.06.2025 um 13:15 +0200 schrieb Alberto Garcia: If there is more than install the .deb, reboot and start liferea by terminal then I need advice. I'm not a developer and not used to use tools like dbg or so... Kind regards Thorsten
No need to do anything like that, simply install the packages from here, run liferea from a terminal and send me the output: https://people.debian.org/~berto/webkit2gtk-2.48.3-1+nvidiadbg/ I uploaded the complete build but in principle you only need to install the *-4.1*.deb packages (especially libwebkit2gtk-4.1-0 and libjavascriptcoregtk-4.1-0). Thanks, Berto
Hello Alberto, Am Dienstag, dem 01.07.2025 um 17:40 +0200 schrieb Alberto Garcia: Here we go: $ LANG=C && liferea glGetString(GL_VENDOR) returned 'Mesa' NVIDIA card not detected AcceleratedBackingStoreDMABuf::checkRequirements() returned true AcceleratedBackingStoreDMABuf::checkRequirements() returned true <sys>:0: Warning: g_atomic_ref_count_dec: assertion 'old_value > 0' failed KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 469x186: Permission denied Hope that help you. I will return to the "normal" packages because the update deinstalled gir1.2-javascriptcoregtk-4.1 gir1.2-webkit2-4.1 rednotebook If you want me to do more tests, don't hesitate to ask. Kind regards Thorsten
Oh, so glxinfo returns 'NVIDIA Corporation' but WebKit sees 'Mesa' instead. Thanks, it seems that we need to update the patch to detect NVIDIA cards. Berto
How many cards do you have in /dev/dri/card*? Can you paste the output of the 'drmdevice' program? If you have many devices you can also run liferea with WEBKIT_WEB_RENDER_DEVICE_FILE=/dev/dri/cardX once with each one of them. Berto
Am Dienstag, dem 01.07.2025 um 23:18 +0200 schrieb Alberto Garcia:
Only one
# ls /dev/dri/
by-path card0 renderD128
# drmdevice
--- Checking the number of DRM device available ---
--- Devices reported 1 ---
--- Retrieving devices information (PCI device revision is ignored) ---
device[0]
+-> available_nodes 0x05
+-> nodes
| +-> nodes[0] /dev/dri/card0
| +-> nodes[2] /dev/dri/renderD128
+-> bustype 0000
| +-> pci
| +-> domain 0000
| +-> bus 0f
| +-> dev 00
| +-> func 0
+-> deviceinfo
+-> pci
+-> vendor_id 10de
+-> device_id 0fff
+-> subvendor_id 103c
+-> subdevice_id 094a
+-> revision_id IGNORED
--- Opening device node /dev/dri/card0 ---
--- Retrieving device info, for node /dev/dri/card0 ---
device[0]
+-> available_nodes 0x05
+-> nodes
| +-> nodes[0] /dev/dri/card0
| +-> nodes[2] /dev/dri/renderD128
+-> bustype 0000
| +-> pci
| +-> domain 0000
| +-> bus 0f
| +-> dev 00
| +-> func 0
+-> deviceinfo
+-> pci
+-> vendor_id 10de
+-> device_id 0fff
+-> subvendor_id 103c
+-> subdevice_id 094a
+-> revision_id a1
--- Opening device node /dev/dri/renderD128 ---
--- Retrieving device info, for node /dev/dri/renderD128 ---
device[0]
+-> available_nodes 0x05
+-> nodes
| +-> nodes[0] /dev/dri/card0
| +-> nodes[2] /dev/dri/renderD128
+-> bustype 0000
| +-> pci
| +-> domain 0000
| +-> bus 0f
| +-> dev 00
| +-> func 0
+-> deviceinfo
+-> pci
+-> vendor_id 10de
+-> device_id 0fff
+-> subvendor_id 103c
+-> subdevice_id 094a
+-> revision_id a1
Kind regards
Thorsten
Can you export GBM_BACKEND=nvidia-drm and try again? Does it make a difference? Berto
Do you have libnvidia-allocator1 and libnvidia-egl-gbm1 installed? If not, install them and try again (with and without setting GBM_BACKEND). Berto
Does exporting GBM_BACKENDS_PATH=/usr/lib/x86_64-linux-gnu/nvidia/current make a difference? Berto
Hello Alberto, Am Donnerstag, dem 17.07.2025 um 09:37 +0200 schrieb Alberto Garcia: gnu/nvidia/current && liferea Could not create GBM EGL display: EGL_NOT_INITIALIZED. Aborting... Aborted (core dumped) Liferea doesn't even start Kind regards Thorsten
Set also GBM_BACKEND=nvidia-drm in addition to GBM_BACKENDS_PATH Berto
Am Donnerstag, dem 17.07.2025 um 17:15 +0200 schrieb Alberto Garcia: LANG=C && GBM_BACKENDS_PATH=/usr/lib/x86_64-linux-gnu/nvidia/current && GBM_BACKEND=nvidia-drm && liferea <sys>:0: Warning: g_atomic_ref_count_dec: assertion 'old_value > 0' failed KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 469x199: Permission denied Liferea starts but the third window is empty Regards Thorsten
I think that you need to remove those '&&', otherwise liferea won't get those variables. $ COLOR=green && SHAPE=circle && sh -c 'echo $COLOR $SHAPE' $ COLOR=green SHAPE=circle sh -c 'echo $COLOR $SHAPE' green circle Berto
Am Donnerstag, dem 17.07.2025 um 18:24 +0200 schrieb Alberto Garcia: GBM_BACKEND=nvidia-drm && liferea <sys>:0: Warning: g_atomic_ref_count_dec: assertion 'old_value > 0' failed KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied KMS: DRM_IOCTL_MODE_CREATE_DUMB failed: Permission denied Failed to create GBM buffer of size 469x199: Permission denied Result is the same: Liferea starts but the window is empty Regards Thorsten
Hi Thorsten, if you are still having this issue with liferea (or other WebKit-based apps) I would like to try something else. Can you build and run the attached program and paste the output? It should be something like this: $ gcc -o drmdriver -I/usr/include/libdrm drmdriver.c -ldrm $ ./drmdriver /dev/dri/renderD128: 'i915' Also, if you can confirm what version of Debian you're using (trixie, testing, sid, ...) and the exact versions of the webkit packages I can maybe prepare a test build with a possible workaround. Thanks! Berto