ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<kchibisov>
Is it normal that I have a device that never returns a wl_pointer::button releases only presses? What should I try to do if I rely on releases to start events?
<kchibisov>
It's some laptop touchpad and in WAYLAND_DEBUG=1 log I only see wl_pointer events for press...
<orowith2os>
that sounds like a bug?
<kchibisov>
But in what in libinput?
<kchibisov>
Or in my client that I rely only releases to execute action?
<jadahl>
kchibisov: 'sudo libinput debug-events' will tell you what libinput saw
<orowith2os>
kchibisov it doesn't sound right for a wl_pointer button state to never be released, so I'd say a bug in libinput
<emersion>
could also be a compositor bug
<kchibisov>
We'll see, if I'll see the logs in the libinput I'll redirect them to mutter.
<orowith2os>
emersion innocent until proven guilty :P
<emersion>
in my experience that doesn't work too well in computer "science"
<emersion>
each and every layer in the stack has a bug until proven otherwise
Plasm0duck has quit [Ping timeout: 480 seconds]
<kchibisov>
At least, I don't think it's my client issue.
fmuellner has joined #wayland
<jadahl>
kchibisov: what's the debug log?
<kchibisov>
jadahl: the wayland one or libinput?
<jadahl>
assuming libinput produces correct events, the wayland one
<kchibisov>
I'm still waiting for libinput log.
<kchibisov>
I'm just forwarding bug I was reported further.
<kchibisov>
I have wayland log though.
<kchibisov>
And it never has a wl_pointer::button(.., 0).
<kchibisov>
Only wl_pointer::button(.., 1), which is press.
<kennylevinsen>
And I presume no wl_pointer::leave/enter in between?
<kchibisov>
There's a leave after press.
Plasm0duck has joined #wayland
<kchibisov>
But when they use mouse they have the event right away and I also have button release with mouse in the exact same situation.
<kennylevinsen>
oh well, we will know more when we have libinput and wayland debug :)
<kchibisov>
The events are press -> frame -> leave (due to move on xdg_shell) -> frame -> enter -> frame.
<jadahl>
xdg_toplevel.move() makes the surface loose pointer focus - that means no up event. that is how it works here, both with a mouse and touchpad, and that is correct behavior
<pq>
Ishq, how do you know which input devices the desktop actually uses, which desktop instance you should target, and how do you avoid the desktop compositor reacting to the same gesture? Or parts of the gesture unexpectedly being reacted to by the compositor or apps?
<pq>
Ishq, how are you even able to open the input devices?
<kchibisov>
jadahl: hm, yeah, I think the issue is that they tap really slow, so they never trigger other path and that's why I've got confused that I only see presses.
<kchibisov>
Is 300ms between pointer clicks is that low?
<jadahl>
kchibisov: I can easily get 5000ms between press and release, I just need to hold the button down on my mouse :P
<kchibisov>
(to consider a double click) or their touchpad is just slow? Because with mouse they were able to do that.
<kennylevinsen>
note: wl_pointer.leave does not actually describe an implicit release bahavior...
<kchibisov>
Yeah, but they want a double click.
<kennylevinsen>
only wl_keyboard.leave seem to do that
epony has quit [Remote host closed the connection]
<emersion>
sounds like an oversight…
<kennylevinsen>
indeed
epony has joined #wayland
<kchibisov>
Like gtk2 had this property at 250ms.
<kchibisov>
Ah, gtk4 uses 400ms, I wonder why.
<pq>
kchibisov, your client is correct to rely on button release events to trigger stuff. If you receive two the same button down events in a row, with no up of wl_pointer.leave/enter pair in between, that's a bug in the compositor or below.
i509vcb has quit [Quit: Connection closed for inactivity]
<kchibisov>
Yeah, I just wasn't sure how leave interacts with all of that, because it doesn't say anything.
<pq>
wl_pointer.leave means you don't have the pointer anymore, so you cannot know its state anymore
<pq>
wl_pointer.leave is *not* an implicit button-up
<pq>
if you get wl_pointer.leave, you are not supposed to run button-up handlers
<pq>
yup. wl_pointer.enter/leave spec is indeed lacking
<kennylevinsen>
you could also word it as "button up should only be run on explicit release", but yeah
cmichael has joined #wayland
carlos_ has joined #wayland
<pq>
the same thing as with keyboard up/down/leave, expect wl_pointer cannot enter with buttons down
<pH5>
daniels: I think I don't understand your feedback on !1312.
<pH5>
I have goal to do per-output textures, and I don't see how this change would force outputs to do full uploads.
<pH5>
All gl_renderer flush_damage() does is push down surface damage to gb->texture_damage and either let it sit there or upload all damage rectangles to the texture and clear that in one go.
<pH5>
But I see no reason it couldn't be more (or differently) clever about partial uploads and partial clearing of gb->texture_damage.
<pH5>
s/I have goal to do per-output textures/I have no goal to do per-output textures/
<daniels>
pH5: heh, the sense negation does really change things ... :)
sunrise890 has joined #wayland
<daniels>
pH5: I think I see what you mean then - the surface texture is shared between multiple output contexts, but you at least know which output context to bind in flush_damage, because it'll be the next repaint()
dmitz[m] has joined #wayland
sunrise890 has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
<pH5>
daniels: Kind of, yes. The idea was to let flush_damage() memcpy into a staging VkBuffer and record vkCmdCopyBufferToImage calls into a per-output VkCommandBuffer. repaint_output() can then pick it up and queue it together with the necessary image barriers.
Company has quit [Remote host closed the connection]
wb9688 has quit [Remote host closed the connection]
wb9688 has joined #wayland
manuels has joined #wayland
Company has joined #wayland
ahartmetz has joined #wayland
ukiran1 has quit [Ping timeout: 480 seconds]
rasterman has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
paulk-bis has quit []
paulk has joined #wayland
rgallaispou has joined #wayland
epony has quit [Remote host closed the connection]
dmitz[m] has quit [Quit: issued !quit command]
tzimmermann has quit [Quit: Leaving]
rgallaispou has left #wayland [#wayland]
dmitz has joined #wayland
crazybyte has quit [Ping timeout: 480 seconds]
crazybyte has joined #wayland
cmichael has quit [Quit: Leaving]
gfxstrand has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
junaid has quit [Ping timeout: 480 seconds]
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
<daniels>
pH5: iswym, but I guess you'd then need to look across outputs; if you flush damage for a surface in output A's cmdbuf, output B would then need to sync against the completion before it used that surface's VkImage?
<daniels>
which was my point
karmavil[m] has joined #wayland
<karmavil[m]>
"You don't have permission to view messages from before you joined."
<karmavil[m]>
Oh wow that it very helpful. Now I will be force to ask
<daniels>
pH5: btw, I've avoided ivi-shell until now since I don't have any representative tests; would you be ok to move it to weston_view_move_to_layer + weston_view_set_alpha + weston_view_add_transform + etc, and making sure that it never manipulates those as well as never calls weston_view_geometry_dirty/weston_view_update_transform/etc?
<karmavil[m]>
What happened to `weston-launch`? It is not available. I've just installed weston from the repository.
<karmavil[m]>
I guess it is related to the properties of my computer. It doesn't support virtualization. Could you confirm or deny this suspicious?
<karmavil[m]>
weston-launch is still referred in the documentation as a command to run
<karmavil[m]>
* What happened to `weston-launch`? It is not available. I've just installed weston package(apt) <del>from the repository</del>.
<karmavil[m]>
I guess it is related to the properties of my computer. It doesn't support virtualization. Could you confirm or deny this suspicious?
<karmavil[m]>
$ weston --version
<karmavil[m]>
weston 10.0.1
<daniels>
karmavil[m]: it got replaced by seatd-launch
<daniels>
it's nothing to do with virtualisation, just that we chose to make weston rely on either logind or libseat when launched from a VT
* JEEB
has been utilizing this one for a good while
<jadahl>
yes that one
rv1sr has quit []
<vyivel>
how should compositors handle xdg_popup.grab and wl_data_device.start_drag sent with the same user event serial? allow the first, reject everything else?
<jadahl>
being a bit strict, if the popup is popped up first, the grab is no longer implicit, so the start_drag should fail. if the start_grab came first, then I guess it should be allowed, followed by the popup being allowed to be popped up
<jadahl>
vyivel: perhaps it shouldn't, I'm not sure. I suspect the drag creates its own grab, and that breaks the popup grab, dismissing it, but that's a wild guess
nerdopolis has joined #wayland
<vyivel>
what mutter does is what i'd expect it to do tbh
<vyivel>
i guess a better question would be
<vyivel>
what is a grab?
<vyivel>
wayland doesn't seem to define it
<jadahl>
an implicit grab is when a pointer button is pressed on a surface and the surface keeps receiving input events and the release button despite the pointer leaving the surface
<jadahl>
it has an implicit "grab" during the "click"
<jadahl>
an explicit grab is what xdg_popup.grab defines as receiving input pointer events on all surfaces if the pointer is above any of them, but other clients surfaces wont receive events. it also talks about keyboard focus following the popup grab
<emersion>
implicit grab is also used for xdg_toplevel.move iirc
<emersion>
and resize
<emersion>
i suppose the implicit grab is created when the pointer button down event is sent, and then "transfered" into a move/rezize action later on
<vyivel>
right, same with dnd
<vyivel>
but how dnd works with explicit grabs is unclear
<jadahl>
same with .move and .resize I guess
<emersion>
so, start an explicit grab with a popup, then start dnd from that popup?
sima has quit [Ping timeout: 480 seconds]
<any1>
Wasn't there a w-p meeting today?
carbonfiber has quit [Quit: Connection closed for inactivity]
<zamundaaa[m]>
any1: yes there was
Brainium has joined #wayland
AndrewYu has quit [Remote host closed the connection]
DodoGTA has quit [Remote host closed the connection]
mxz has joined #wayland
ahartmetz has quit [Remote host closed the connection]
jmdaemon has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
floof58 has quit [Ping timeout: 480 seconds]
gfxstrand has joined #wayland
floof58 has joined #wayland
DodoGTA has joined #wayland
epony has joined #wayland
natewrench has joined #wayland
<natewrench>
hello, has wayland been implemented or featured in any new distros?
<LaserEyess>
most major distros support all major wayland compositors
<LaserEyess>
anything that supports gnome or kde supports wayland
eroc1990 has quit [Quit: Ping timeout (120 seconds)]
<natewrench>
LaserEyess: I am using Linux Mint 21.2 Vanessa so I think I wont see wayland for about another year when Ubuntu 24.04 releases (Mint is based on LTS Ubuntu releases).
eroc1990 has joined #wayland
<LaserEyess>
ubuntu 22.04 ships with wayland by default
JoshuaAshton has quit [Quit: Gone froggin!]
<natewrench>
LaserEyess: well the only thing I have in Mint is wayland-scanner
<LaserEyess>
wayland isn't a program
<LaserEyess>
if you use gnome 42 you are using wayland
<natewrench>
LaserEyess: im on cinnamon
<LaserEyess>
I have no idea then
FLHerne has quit [Quit: There's a real world out here!]