I haven't been able to create a PM with them before, only by trying to log in as a registered user and having them initiate a message that the username is taken
Creak: I didn't. I registered via a different IRC client, then told Matrix to use that IRC username
for the others readin, jenatali is not talking to himself, I'm on the other side (Matrix) and try to identify my username there ;)
OFTC's integration is pretty bad IME
Creak is now known as Guest9144
Creak[m] is now known as Creak
yes! it works!
So the solution was to open a DM with @_oftc_NickServ:matrix.org and enter `IDENTIFY <password> Creak`
Guest9144 has quit 
I agree. That's why with meson we used a bridged room instead of an irc bridge
From matrix 😉
And I verified in another IRC client that my message was displayed
you can't speak on this IRC chan without a registered user, indeed
(or only the Matrix users will see your messages, which is not very nice for the IRC users since they'll only have half the discussion)
pcercuei has quit [Quit: brb]
pcercuei has joined #dri-devel
Creak has left #dri-devel [#dri-devel]
zf has joined #dri-devel
is there a canonical bug report for "nouveau doesn't support multithreading"?
Hi folks, anybody ever seen "[drm] Failed to add display topology, DTM TA is not initialized." with amdgpu ?
glEnable(GL_FRAMEBUFFER_SRGB) seems to cause ALL framebuffer writes to be converted to sRGB, even if the attachment is not an sRGB format. According to the 4.6 spec, this is wrong (17.3.7 sRGB Conversion). Am I misreading it or did i just find a bug?
zf: Not really, but if you're careful you can still take advantage of multithreading :P
well, sure, I was hoping there'd be a bug report I can track
I don't suppose mesa would be interested in creating one? :D
Issue #3518 might be close enough to track it
jljusten has quit [Quit: WeeChat 3.3]
jljusten has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
pcercuei has quit [Quit: Lost terminal]
palindrome has joined #dri-devel
would it make sense to have an GL_ARB_shadow nir lowering hooked up in main/st or is this more a lowering called in the driver itself?
dviola has joined #dri-devel
pnowack has quit [Quit: pnowack]
ngcortes has joined #dri-devel
pcercuei has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
dviola has left #dri-devel [#dri-devel]
MajorBiscuit has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
pnowack has joined #dri-devel
eletrotupi has quit 
eletrotupi has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
nikitalita48 has quit 
nikitalita48 has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
should reading GL_TIMESTAMP wake a monitor from DPMS?
jewins has joined #dri-devel
I'm trying to figure out if this is a gnome-shell/mutter/cogl bug for reading the timestamp while the monitor is supposed to be asleep or an AMDGPU bug for waking the display to report the timestamp
also bpftrace is pretty great, although I wish it understood DWARF debuginfo
imre: ^ i guess the same thing linus reported
ybogdano has joined #dri-devel
agd5f: hwentlan__: does amdgpu perhaps link train all displays (even if they're supposed to be dpms off) when coming out of runtime suspend?
enum values are always valid constant expressions, but a constant variable in C is never a valid constant expression. If you can express it as an enum (i.e fits in an int) then that should be fine, otherwise you'll need to use defined. Looks like these are uint64_t so yeah you're a bit hosed there.
C has some pretty old rules here. It's kind of funny MSVC rejects it actually since in C++ this is a valid constant expression and MSVC is mostly a C++ compiler.