So, yeah, *&%*($ to silently ignoring errors, XCB.
It turns out sending a closed FD via XCB doesn't fail. The other side (X.Org server) just receives a random FD number, which I think by chance referred to an unrelated FD which was opened.
But why was I sending a closed FD via XCB in the first place? It turns out sending a FD via XCB also closes it. So it worked fine the first time, and caused the bug the second time.
This morning I spent a few hours tracking down a bug in wlroots' X11 backend. Importing a DMA-BUF via the X11 DRI3 extension failed, and I couldn't understand why.
Went from X.Org server core to Xwayland to GBM to Gallium to radeonsi to libdrm to the kernel. The FD seemed valid, since stat() didn't return an error, but drmPrimeFDToHandle failed.
Saying "no" to unethical tasks
A few ways to make money in FOSS
Status update, November 2020
SourceHut's second year in alpha
Join us for basu development:
- Doesn't require to think too hard
- Just delete large chunks code as long as it compiles
- The code you get to delete is terrible, so you'll sleep better afterwards
- Can be seen as payback for all of the bad code you've written during the day
Some doctors even recommend it!
Support for AMD modifiers is being merged in Mesa's radeonsi 🎉
Linux graphics, why sharing code with Windows isn't always a win
SourceHut Q3 2020 Financial report
wlroots 0.12.0 is released!
I don't know why, but sometimes I fall in love with a song on first listening. This just happened with:
Getting pixels on screen on Linux: introduction to Kernel Mode Setting - Simon Ser https://conf.tube/videos/watch/c023f9e8-0bae-4aa1-ac91-bfc5f21c46aa
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!