ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<whot>
regarding repeat: the kernel does key repeat (with a value of 2), that's what you'll see when you look at the event node with e.g. libinput record. The repeat delay/rate is configurable via an ioctl, and all that is the key repeat you'd see on a vt
aknot has joined #wayland
<whot>
XKB has its own key repeat which the server is doing, decades ago we had some issues with the kernel repeat keys interfering with XKB repeat keys resulting in "pulsing" repeats where you'd get aa aaaaa a aaaaa depending how the rates interfered with each other. in 2008 the evdev driver stated filtering all kernel repeat events and thus forcing XKB repeat only (XKB was made mandatory
<whot>
a few xserver releases before)
<whot>
XKB also has a per-key repeat setting so you can set some keys to repeat and others not
<whot>
libinput does the same as the evdev driver, it filters all kernel repeats, so you won't see any of those in libinput debug-events
<whot>
which all makes sense on a local setup where any delay between HW and processing would be a bug :)
Guest495 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest502
nerdopolis has quit [Ping timeout: 480 seconds]
silverpower has quit [Ping timeout: 480 seconds]
silverpower has joined #wayland
bindu_ has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
glennk has joined #wayland
aknot has quit [Ping timeout: 480 seconds]
calcul0n has joined #wayland
lanodan has quit [Ping timeout: 480 seconds]
lanodan has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
Company has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
fmuellner has quit [Read error: Connection reset by peer]
junaid has joined #wayland
calcul0n has quit [Remote host closed the connection]
calcul0n has joined #wayland
junaid has quit [Quit: leaving]
calcul0n has quit [Remote host closed the connection]
calcul0n has joined #wayland
calcul0n has quit []
calcul0n has joined #wayland
JakeSays has joined #wayland
mxz has joined #wayland
JakeSays1 has quit [Ping timeout: 480 seconds]
calcul0n has quit [Quit: Leaving]
garnacho has joined #wayland
rasterman has joined #wayland
Leopold_ has quit []
Leopold_ has joined #wayland
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
Leopold__ has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
leon-anavi has joined #wayland
glennk has joined #wayland
junaid has joined #wayland
tyzef has joined #wayland
junaid has quit [Remote host closed the connection]
<emersion>
point (3) is the exact contrary of an earlier discussion we had
<emersion>
i originally had an error for set_*_point called twice between commits, and you and swick[m] argued that it shouldn't be a protocol error for consistency with the rest of the protocols
<emersion>
daniels, do you mean that pending state may not be discarded by the compositor?
<pq>
I've been thinking of trying bichon again...
<daniels>
emersion: yeah, that the compositor may take the acquire point into account and may set the release point
<daniels>
or it may not
<emersion>
hm, that'd be surprising i think
<daniels>
just seems like it makes it easier for implementations rather than a guarantee that it _will_ be discarded
<emersion>
it would be like implicitly committing pending state
<daniels>
would it?
<daniels>
oh, iswym
<daniels>
hmm
<emersion>
the compositor should completely ignore the pending state as long as there's no commit
<daniels>
yeah, I guess I'm thinking it would just be easier than reaching into pending state you've already stored away and undoing it
<emersion>
i guess i'm not really seeing how this could help in the implementation
<daniels>
right, but I mean, in the case where you have surface.attach(); sync.set_acquire_point(); sync.destroy(); commit(); then you'd have to go into your surface pending state and remove the acquire point
<daniels>
whereas with a 'may' you could either leave the acquire point in the pending state or clear it out, as you pleased
<emersion>
daniels, same if you set_acquire_point() twice
<daniels>
true true
<emersion>
you need to "unset" the previous point either way
<emersion>
ah, i see…
<daniels>
I don't feel strongly about it, just seemed like an easy win which could help implementations and probably no issue for clients as it's a pretty nonsensical thing to do anyway
<emersion>
it comes from the fact you have a monolithic surface state struct i suppose
<emersion>
with All Of The State
<daniels>
right, rather than something composed by addons
<daniels>
which might change, let's see
<daniels>
amazingly, this is one of the things which is not complicated by subsurfaces :P
<emersion>
yeah, no judgment here, the addon stuff adds some substantial complexity
<daniels>
tbf I have a branch where I steal wlr_addon, just keep forgetting to push it
Brainium has joined #wayland
* emersion
has finally reached the "whatever you say i don't really care anymore" mindset on this MR :P
* Eighth_Doctor
is poking all his known consumers of fullscreen shell to switch to kiosk shell
<Eighth_Doctor>
I'm also now co-maintainer of Weston in Fedora :P
<Eighth_Doctor>
hmm maybe I should file a bug about weston not being compatible with freerdp3
Leopold has quit [Ping timeout: 480 seconds]
<daniels>
orly?
junaid has joined #wayland
<daniels>
I swear they only smashed their API to bits like last week
<Eighth_Doctor>
I'm trying to get rid of freerdp2 in Fedora before Fedora 40 GA
<Eighth_Doctor>
I have a terrible feeling I won't be able to, but I can at least try
<daniels>
frdp3 isn't packaged in Debian/Ubuntu, so we'd either have to fork the backend or shed support for those distros ...
<Eighth_Doctor>
oof
<daniels>
not in Yocto either
<Eighth_Doctor>
....
<Eighth_Doctor>
am I the first?!
<Eighth_Doctor>
Yocto doesn't count though
<Eighth_Doctor>
since that would be uplifted/added with a new Weston release anyway
<daniels>
3.0.0 says 'The API should now be considered stable and only minor changes (if at all) will happen from this point on, so every project using FreeRDP can check compatibility with upcoming 3.0'; 3.3.0 released just now breaks the API. sweet.
<Eighth_Doctor>
wait, seriously?!
<daniels>
y
junaid has quit [Remote host closed the connection]
<daniels>
well, they say 'some [...] inconvenient API functions were fixed on the way', which I'm going to assume is an API break
* Eighth_Doctor
facepalms
<daniels>
as for Yocto, there are a lot of downstreams who don't necessarily follow the very latest Yocto but do update versions of other things - and there's no Yocto packaging at all for 3.x, soooo
sgdr_ has joined #wayland
mripard_ has joined #wayland
<Eighth_Doctor>
it looks like the API changes in 3.3.0 are related to winpr for supporting images in clipboards
<Eighth_Doctor>
at least I don't see anything else significant
<daniels>
seems like they're all fairly benign and probably backwards-compatible with 3.0 use
<Eighth_Doctor>
yeah
<Eighth_Doctor>
which makes me feel better about updating to 3.3.0 in fedora 40+ just now 😅
rgallaispou has quit [Remote host closed the connection]
kts has joined #wayland
amosbird has joined #wayland
junaid has quit [Quit: leaving]
junaid has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
silverpower has quit [Ping timeout: 480 seconds]
silverpower has joined #wayland
<amosbird>
whot: Hello! I have been using Thinkpad X1E Gen 3 with Archlinux + X + libinput for more than two years. Everything works just fine except that 3-finger gesture intermittenlty fails. Usually it stops working right after carrying on some 4-finger gesture. The only way to make 3-finger gesture work again is to trigger another 4-finger gesture.
<amosbird>
Someday I updated my kernel with https://github.com/torvalds/linux/commit/7984b43542070f5888546d95b48003c4a8af7c0f. After this update, the name of my touchpad becomes "Synaptics TM3625-010" instead of "SynPS/2 Synaptics TouchPad". Since then the touchpad became quite laggy during movement. Surprisingly, all multi-finger gestures work perfectly!
<amosbird>
I'm aware that setting psmouse.synaptics_intertouch=0 in kernel cmdline will make it back to SynPS/2, but the 3-finger gesture issue will regress. Is there a way to have either "TM3625-010" get smooth movement or "SynPS/2" with healthy 3-finger gesture?
rgallaispou has joined #wayland
IMTheNachoMan has quit [Quit: Connection closed for inactivity]
calcul0n has joined #wayland
tyzef has joined #wayland
leon-anavi has quit [Remote host closed the connection]
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
<bwidawsk>
AFAICT, xdg_toplevel::configure should (for the current version anyway) specify negative values for width and height are disallowed - or is there something I'm missing?
junaid has quit [Remote host closed the connection]
calcul0n has quit [Quit: Leaving]
Company has quit [Quit: Leaving]
<bwidawsk>
I'm also confused about xdg configure/ack. ack_configure wants a serial, but it seems like there is a sequence of events which would result in toplevel.configure being sent without a surface.configure, and then what serial would you use
<emersion>
no, a xdg_toplevel configure is always followed by xdg_surface.configure
<emersion>
clients should buffer what they receive in xdg_toplevel.configure
<emersion>
and apply to on xdg_surface.configure
<emersion>
it*
<emersion>
apply as in act on
hays has quit [Remote host closed the connection]
Leopold__ has quit [Remote host closed the connection]
JakeSays1 has quit [Read error: Connection reset by peer]
Leopold has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
JakeSays has joined #wayland
junaid has joined #wayland
hays has joined #wayland
junaid has quit [Remote host closed the connection]
hays has quit []
hays has joined #wayland
sima has quit [Ping timeout: 480 seconds]
<bwidawsk>
emersion: so basically until get_popup or get_toplevel, hang on to the last surface configure, yes?
<emersion>
I don't understand
<bwidawsk>
If a client does get_xdg_surface; commit, a configure event should be sent
<bwidawsk>
then the client does get_toplevel, a toplevel configure event would be sent
<bwidawsk>
agree so far?
tyzef has joined #wayland
<bwidawsk>
emersion: ^^
<bwidawsk>
or would it go, get_toplevel(); commit(); // get both configure events?
<vyivel>
bwidawsk: get_{toplevel,popup} is sent at most once for a given xdg_surface
<vyivel>
before that, xdg_surface has no associated xdg surface role object
<bwidawsk>
vyivel: yeah, it's the configure event I'm interested in here
<vyivel>
iirc you're not even allowed to commit in this state
<vyivel>
yeah so
<bwidawsk>
which, with no role?
<vyivel>
xdg_surface.configure marks the end of a configure sequence
<vyivel>
which can consist of multiple events
<vyivel>
e.g. xdg_toplevel.configure, zxdg_toplevel_decoration_v1.configure, xdg_surface.configure
<vyivel>
the client must treated the above sequence as an atomic configuration request
<vyivel>
what are you trying to do btw?
<bwidawsk>
vyivel: test suite
<vyivel>
aha
<bwidawsk>
vyivel: so indeed, surface.configure marks the end of a configure and that does answer the question, it *does* seem you can end up with multiple configure sequences though for toplevel/popup and surfaces that build on top of these
<bwidawsk>
however, they all end with surface.configure
<bwidawsk>
thanks
<bwidawsk>
I think this should be reworded though if the intention is the sequence is all configure events
<bwidawsk>
`The configure event marks the end of a configure sequence. A configure sequence is a set of one or more events configuring the state of the xdg_surface, including the final xdg_surface.configure event.`
<vyivel>
wdym?
<vyivel>
seems pretty clear to me
<bwidawsk>
the events configure the state of something higher level perhaps than an xdg_surface
<bwidawsk>
ie. toplevel in an simple example
<bwidawsk>
or if you look at some other external protocols
<vyivel>
"the state of the xdg_surface and associated objects" maybe then, idk
<vyivel>
xdg_surface by itself isn't very useful so some other, actually useful, object is implied there
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
sevz has quit [Quit: WeeChat 4.2.1]
sevz has joined #wayland
sgdr_ has quit [Remote host closed the connection]
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
yang2 has quit [Remote host closed the connection]