00:38 wlb: wayland Merge request !328 opened by Volodymyr Zolotopupov (zvova7890) Draft: protocol: add scale120 event to the wl_output https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/328
02:58 wlb: weston Issue #776 opened by Dudemanguy (Dudemanguy) Segfault when destroying shm buffers in a client https://gitlab.freedesktop.org/wayland/weston/-/issues/776
07:02 zzag: jadahl: does gtk support the cursor-shape-v1 protocol? or are there plans to implement it?
07:04 orowith2os: hope ya don't mind me popping in :D
07:04 orowith2os: I'm not seeing any hits for cursor-shape in the gitlab search
07:04 orowith2os: no issues too
07:09 kchibisov: orowith2os: https://wayland.app/protocols/cursor-shape-v1
07:10 Company: it doesn't because nobody has implemented it yet
07:11 orowith2os: kchibisov I was referring to the gnome gtk gitlab search, I know about the cursor-shape-v1 protocol :P
07:11 kchibisov: Ah, it's not clear which gitlab.
07:11 orowith2os: fair
07:11 orowith2os: thanks for linking it anyways, I wanted to give it a quick read
07:12 Company: GTK has https://docs.gtk.org/gdk4/ctor.Cursor.new_from_name.html so it's just a job to hook it up
07:13 orowith2os: actually, I wonder, why are there different named positions for some cursors, like resizing?
07:13 orowith2os: could you not just specify a rotation to go with them instead, so the cursor itself has one name?
07:13 Company: shadows etc
07:13 orowith2os: i.e. wp_cursor_shape_device_v1::shape and wp_cursor_shape_device_v1::rotation
07:14 Company: also, this just copies functionality from X11, win32, etc
07:15 Company: so being different just makes it more work to support
07:15 orowith2os: fair, couldn't hurt to ask at least
07:18 emersion: in your cursor theme, cursors have a name, they don't have a rotation
07:18 emersion: client libs can offer functions to convert a rotation into a name
07:19 emersion: no need to add more complexity to the protocol for that
08:07 wlb: weston Merge request !1312 opened by Philipp Zabel (pH5) Add output parameter to renderer->flush_damage() and use it in the GL renderer https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1312
08:23 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?
08:24 kchibisov: It's some laptop touchpad and in WAYLAND_DEBUG=1 log I only see wl_pointer events for press...
08:26 orowith2os: that sounds like a bug?
08:26 kchibisov: But in what in libinput?
08:27 kchibisov: Or in my client that I rely only releases to execute action?
08:27 jadahl: kchibisov: 'sudo libinput debug-events' will tell you what libinput saw
08:28 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
08:28 emersion: could also be a compositor bug
08:28 kchibisov: We'll see, if I'll see the logs in the libinput I'll redirect them to mutter.
08:29 orowith2os: emersion innocent until proven guilty :P
08:29 emersion: in my experience that doesn't work too well in computer "science"
08:30 emersion: each and every layer in the stack has a bug until proven otherwise
08:32 kchibisov: At least, I don't think it's my client issue.
08:42 jadahl: kchibisov: what's the debug log?
08:42 kchibisov: jadahl: the wayland one or libinput?
08:43 jadahl: assuming libinput produces correct events, the wayland one
08:43 kchibisov: I'm still waiting for libinput log.
08:43 kchibisov: I'm just forwarding bug I was reported further.
08:44 kchibisov: I have wayland log though.
08:44 kchibisov: And it never has a wl_pointer::button(.., 0).
08:44 kchibisov: Only wl_pointer::button(.., 1), which is press.
08:48 kennylevinsen: And I presume no wl_pointer::leave/enter in between?
08:48 kchibisov: There's a leave after press.
08:49 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.
08:51 kennylevinsen: oh well, we will know more when we have libinput and wayland debug :)
08:51 kchibisov: The events are press -> frame -> leave (due to move on xdg_shell) -> frame -> enter -> frame.
09:00 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
09:01 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?
09:01 pq: Ishq, how are you even able to open the input devices?
09:03 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.
09:03 kchibisov: Is 300ms between pointer clicks is that low?
09:04 jadahl: kchibisov: I can easily get 5000ms between press and release, I just need to hold the button down on my mouse :P
09:04 kchibisov: (to consider a double click) or their touchpad is just slow? Because with mouse they were able to do that.
09:04 kennylevinsen: note: wl_pointer.leave does not actually describe an implicit release bahavior...
09:04 kchibisov: Yeah, but they want a double click.
09:04 kennylevinsen: only wl_keyboard.leave seem to do that
09:04 emersion: sounds like an oversight…
09:04 kennylevinsen: indeed
09:06 kchibisov: Like gtk2 had this property at 250ms.
09:06 kchibisov: Ah, gtk4 uses 400ms, I wonder why.
09:07 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.
09:08 kchibisov: Yeah, I just wasn't sure how leave interacts with all of that, because it doesn't say anything.
09:10 pq: wl_pointer.leave means you don't have the pointer anymore, so you cannot know its state anymore
09:11 pq: wl_pointer.leave is *not* an implicit button-up
09:11 pq: if you get wl_pointer.leave, you are not supposed to run button-up handlers
09:12 pq: yup. wl_pointer.enter/leave spec is indeed lacking
09:13 kennylevinsen: you could also word it as "button up should only be run on explicit release", but yeah
09:14 pq: the same thing as with keyboard up/down/leave, expect wl_pointer cannot enter with buttons down
09:43 wlb: weston Merge request !1313 opened by Daniel Stone (daniels) Automatically schedule view repaints on property changes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1313 [libweston API], [Desktop shell]
10:16 wlb: weston Merge request !1314 opened by Daniel Stone (daniels) Use weston_view_move_to_layer() consistently in desktop-shell https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1314 [Desktop shell]
11:05 daniels: ManMower: ooi do you have a weston_coord_output up your sleeve somewhere?
11:31 wlb: weston Merge request !1315 opened by Daniel Stone (daniels) backend-wayland: Free pixel formats on shutdown https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1315 [Nested Wayland backend]
12:09 ManMower: daniels: I do not.
12:10 daniels: ntw
12:22 pH5: daniels: I think I don't understand your feedback on !1312.
12:23 pH5: I have goal to do per-output textures, and I don't see how this change would force outputs to do full uploads.
12:24 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.
12:24 pH5: But I see no reason it couldn't be more (or differently) clever about partial uploads and partial clearing of gb->texture_damage.
12:25 pH5: s/I have goal to do per-output textures/I have no goal to do per-output textures/
12:56 daniels: pH5: heh, the sense negation does really change things ... :)
12:57 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()
13:22 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.
17:58 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?
17:58 daniels: which was my point
18:00 karmavil[m]: "You don't have permission to view messages from before you joined."
18:00 karmavil[m]: Oh wow that it very helpful. Now I will be force to ask
18:01 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?
18:03 karmavil[m]: What happened to `weston-launch`? It is not available. I've just installed weston from the repository.
18:03 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?
18:04 karmavil[m]: weston-launch is still referred in the documentation as a command to run
18:06 karmavil[m]: * What happened to `weston-launch`? It is not available. I've just installed weston package(apt) <del>from the repository</del>.
18:06 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?
18:07 karmavil[m]: $ weston --version
18:07 karmavil[m]: weston 10.0.1
18:19 daniels: karmavil[m]: it got replaced by seatd-launch
18:20 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
18:22 karmavil[m]: Thank you for taking time and efforts on elaborate an answer.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/UejPIJYHZgiaaOeXLqcrhCYj>)
18:23 emersion: oh good, now long matrix messages get _downloaded_ by browsers
18:23 karmavil[m]: daniels: Oh I think I understand
18:23 emersion: sigh
18:25 Arnavion: Yes they broke that a few weeks ago
18:26 Arnavion: Every media store URL has a content-disposition header now so the browser treats it as a download
18:30 karmavil[m]: <karmavil[m]> "Oh I think I understand" <- and the reply actually answered that is not about virtualization so thank you o7
18:59 jadahl: emersion: reading messages with curl is the new modern UX I guess
19:00 Arnavion: I just wrote a firefox extension to strip the header
19:07 jadahl: I run some firefox extension that nags me with an extra "what to do" dialog where I can "open in firefox"
19:07 jadahl: it helps with it and sometimes opening logs from gitlab/bugzilla
19:07 JEEB: this one perhaps? https://addons.mozilla.org/en-US/firefox/addon/open-in-browser/
19:08 JEEB:has been utilizing this one for a good while
19:08 jadahl: yes that one
19:59 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?
20:05 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
20:07 wlb: wayland Issue #394 opened by Shawn Rutledge (ecloud) Need a generic device tree protocol similar to tablet-unstable-v2 https://gitlab.freedesktop.org/wayland/wayland/-/issues/394
20:09 vyivel: hm, with wl_data_device.start_drag followed by xdg_popup.grab mutter appears to dismiss the popup immediately
20:11 wlb: wayland-protocols Merge request !236 closed (xdg-shell: clarify parent requirements for grabbing popups)
20:12 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
20:14 vyivel: what mutter does is what i'd expect it to do tbh
20:15 vyivel: i guess a better question would be
20:15 vyivel: what is a grab?
20:15 vyivel: wayland doesn't seem to define it
20:17 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
20:17 jadahl: it has an implicit "grab" during the "click"
20:18 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
20:21 emersion: implicit grab is also used for xdg_toplevel.move iirc
20:21 emersion: and resize
20:22 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
20:23 vyivel: right, same with dnd
20:23 vyivel: but how dnd works with explicit grabs is unclear
20:23 jadahl: same with .move and .resize I guess
20:25 emersion: so, start an explicit grab with a popup, then start dnd from that popup?
21:00 any1: Wasn't there a w-p meeting today?
21:13 zamundaaa[m]: any1: yes there was
21:51 bl4ckb0ne: are the notes already up?
21:54 any1: Doesn't look like it: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/wikis/meetings
21:59 Ermine: Are meetings for w-p maintainers only?
23:15 natewrench: hello, has wayland been implemented or featured in any new distros?
23:17 LaserEyess: most major distros support all major wayland compositors
23:18 LaserEyess: anything that supports gnome or kde supports wayland
23:19 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).
23:20 LaserEyess: ubuntu 22.04 ships with wayland by default
23:25 natewrench: LaserEyess: well the only thing I have in Mint is wayland-scanner
23:26 LaserEyess: wayland isn't a program
23:26 LaserEyess: if you use gnome 42 you are using wayland
23:26 natewrench: LaserEyess: im on cinnamon
23:27 LaserEyess: I have no idea then
23:38 psykose: cinnamon doesn't support it iirc