ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
mclasen has quit []
mclasen has joined #wayland
hergertme has quit [Remote host closed the connection]
slattann has quit [Read error: Connection reset by peer]
zebrag has quit [Quit: Konversation terminated!]
hardening has joined #wayland
caveman has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
nsneck_ has quit [Remote host closed the connection]
pseigo has joined #wayland
pseigo has quit [Read error: No route to host]
pseigo has joined #wayland
dcz_ has joined #wayland
dcz has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
caveman has quit [Ping timeout: 480 seconds]
UndeadLeech has quit [Remote host closed the connection]
<MrCooper>
zamundaaa[m]: unfortunate, isn't it? Thankfully, they seem to be working on eliminating that requirement
mbalmer has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
maxzor_ has joined #wayland
<pq>
riteo, maybe your simpler test program doesn't actually live long enough to e.g. receive events the compositor is sending.
<pq>
zamundaaa[m], I would totally expect that changing vrr_enabled requires a modeset, because it's changing video timings.
<jadahl>
pq: it doesn't on amd, only intel. it's a bit annoying there is no way to know beforehand whether so is the case though
<pq>
jadahl, sure, but expectations are not always true. Yet, it makes sense to me that it needs a modeset.
<pq>
and I'm surprised when it doesn't need
<pq>
you probably need to reallocate fifos and whatnot, maybe also re-negotiate the link when changing between fixed-freq and VRR, or so I would imagine
<pq>
unless the KMS UAPI is inteded to *always* negotiate the link with VRR allowed, then the vrr_enable is just a driver toggle on when to flip
<MrCooper>
pq: Intel devs are working on eliminating the requirement from the i915 driver as well
<pq>
also, even if the kernel driver and crtc block allow changing vrr_enabled without modeset, who says the monitor won't die for a moment?
<MrCooper>
the experience of amdgpu VRR users seems to say so :)
<pq>
just like changing some connector properties can cause monitors to black out for a moment even though it's just infoframe data that is changing
<pq>
well, it's really nice if it works without a modeset and blackout
<pq>
I'm just default pessimistic wrt. hardware :-)
<pq>
see also: monitors exhibiting luminance flicker when VRR changes rate too fast
Company has quit [Read error: Connection reset by peer]
CodeSpelunker has quit [Ping timeout: 480 seconds]
andyrtr has joined #wayland
cabal704 has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
maxzor_ has joined #wayland
mclasen has joined #wayland
Pongles has joined #wayland
<Pongles>
Hi, sorry if this is the wrong channel for this but I am looking for help with my graphics tablet, Huion Kamvas 13 (H950P), on Fedora 36 KDE Plasma. Overall it works but once I lift the pen off of it (past hover range) for the first time, it stops controlling the mouse until I unplug and re-plug it.
<Pongles>
I know from evtest that it is still tracking as the Table Monitor Pen still outputs the correct values
<i509VCB>
I think this is an issue for KDE
<Pongles>
Is it? I tried there first but I can go back to them
<i509VCB>
does some other DE/WM exhibit this behavior?
<Pongles>
I am not sure, I haven't gotten that far in testing