01:01orowith2os: Ishq you'll have to ask your compositor developers, Wayland doesn't allow arbitrary clients to interact with others.
01:01orowith2os: wlroots probably has some way (for all wlroots compositors) to do that, GNOME has some stuff built in I think, and KDE most definitely does
02:21danieldg: wlroots doesn't have a way for all, that's only in more specific protocols (sway ipc, for example)
02:22danieldg: you can get the *focused* window with foreign-toplevel (the taskbar protocol) but that's not hover
06:21zzag: Has the meeting date and time been decided?
06:25emersion: yes: https://lists.freedesktop.org/archives/wayland-devel/2023-July/042858.html
06:29zzag: Oh blind me.. Thanks!
08:38Ishq: orowith2os: got it. Thanks. I was afraid of that. I've read about the xdg-foreign protocol which might be interesting though
08:56Ishq: Seems there is no API to query exported surfaces :(
08:57jadahl: Ishq: what is it exactly you want to do?
08:58emersion: xdg-foreign is for one specific use-case
08:58emersion: parenting toplevels from two different processes
08:59pq: Ishq, it would help to explain what you want to do from an end user experience point of view, before you decide you need a specific API.
09:03Ishq: I'm trying to update my multitouch gesture recognition app to work on Wayland. One of the features is that it can have per-app gestures. In X11, I would be able to query the "focused" app and use that to figure out what gestures to use. I'm looking for analogous functionality in Wayland
09:03Ishq: Technically, the app itself works fine in wayland except for the perapp gesture thing
09:04emersion: there is no cross-desktop API for this atm
09:04emersion: wlroots and other compositors have a foreign-toplevel protocol
09:06Ishq: I guess that's fine...I plan to use sway anyways. I was hoping for something better than parsing get_tree. I'll read the wlroots code to see what they do with foreign surfaces and if there is an API to query them.
09:45pq: I'm slightly curious how that app can work on Wayland at all.
11:09immibis: that sounds like something that should be in the compositor?
11:10Max1: daniels / jadahl: I mentioned here last week that in this line: https://gitlab.freedesktop.org/wayland/weston/-/blob/main/desktop-shell/shell.c#L1646, `shsurf` might be NULL in some edge cases (popups are involved, fullscreen xdg-toplevels probably as well). Not sure if there's a fix already underway or if I should file a bug so we can keep track of this?
11:10daniels: Max1: yeah, please file a bug - it's definitely NULL in case of popups but I'm not entirely sure what the proper fix is for it
11:10daniels: (and my timeslot expired)
11:11Max1: Ok, will do, thanks!
11:13daniels: np, thank you!
11:26wlb: weston Issue #775 opened by Max Ihlenfeldt (mihlenfeldt) NULL pointer dereference during surface activation sync for popups https://gitlab.freedesktop.org/wayland/weston/-/issues/775
11:48pq: Eh heh. To my latest understanding of EDID, the "default RGB colorimetry" was the closest thing to having source based color management until SBTM becomes usable. The WCG and HDR modes introduced in between just made things more unknowable by invalidating the old colorimetry and offering nothing in its place.
11:52pq: I think we are really going to need tools that end users, who happen to care but not enough to buy profiling equipment, can get an estimate of the color gamut limits in BT.2020 mode.
11:53pq: assumptions galore, but maybe it might lead to subjectively better picture sometimes
11:55pq: I also think we've been using HDR static metadata in infoframes wrong all the time, except video players that just set what the video says.
12:00ukiran: hello pq
12:02ukiran: need little help in reading the color primaries and other transfer characterstics from the LCMS
12:03ukiran: have enabled color-management in the weston server and created a color profile from the icc file..
12:03ukiran: now when i want to read the color primaries from the color profile created from icc file, am getting some values..
12:04ukiran: but the color primaries read from the color profile and the primaries of the widergamut are not matching.. Is it is expected ?
12:04ukiran: reading these cp using lcms lib
12:08ukiran1: pq, btw, i have used /usr/share/color/icc/colord/WideGamutRGB.icc as an icc_file
12:08pq: ukiran, do not try to disassemble an ICC profile to go back to primaries and white point.
12:09ukiran: okay. just wanted to know how a compositor will take a decision on the preferred color space, other color characteristics to create the preferred-image-description
12:09pq: I'm not even sure what you are trying to do.
12:11pq: A surface's preferred image description could be simply the image description of the output where the surface is synchronized to.
12:11pq: Or if a compositor uses a single global blending space, the preferred image description could be derived from that.
12:12pq: If you have an ICC profile, then send the ICC profile as-is to the client, and do not send any other parameters at all.
12:13ukiran: If the client wants to get the image descrption, then the bunch of events needs to be sent to the client with all the color params right ?
12:13ukiran: In this case, do we need send only icc_fd followed by done event ?
12:13pq: No. Only those parameters the compositor had.
12:14pq: If a compositor has an ICC profile, then it has nothing else.
12:14pq: yes
12:15pq: Deriving device primaries and white point from an ICC profile is often not even possible.
12:15ukiran: Yes.. i have got some but dont know whether they are proper or not
12:15ukiran: used some icc-tags to read those..
12:16pq: yeah, and the tags may or may not exist, and then you might be throwing something else away that the profile is doing
12:17ukiran: if the compositor is not using an ICC profile, then how the compositor will create the preferred-image-description ? is it is based on the color space supported by the monitor ?
12:17pq: exactly the same way I explained
12:18pq: you need an image description for each output, and you decide to choose one output as the main output for the surface, and use that output's image description as the surface's preferred one.
12:19pq: *you can decide to choose
12:19pq: Where to get the output image description is a much harder problem. EDID is practically useless.
12:20pq: well, theoretically useless, I don't know about practise yet
12:21pq: there might be something that libdisplay-info does not parse yet, but lacking that, I guess one has to either guess (pick something from a short list of standards), or measure (needs equipment).
12:22ukiran: could you please point me what libdisplay-info is not parsing yet ?
12:22ukiran: i have included libdisplay-info as part of my experiments and able to read the color-space information
12:23pq: ukiran, I don't know what libdisplay-info is not parsing yet that would be relevant here.
12:23pq: ukiran, please, read the docs of the proposed API here: https://gitlab.freedesktop.org/emersion/libdisplay-info/-/merge_requests/167
12:24pq: There is nothing useful that I know of for any HDR mode.
12:25ukiran: okay
12:28ukiran: if we know the colorspace of the monitor,can we hardcode the primaries, tf, other parameters hard coded to create the image description object.
12:28pq: sure
13:20wlb: weston Merge request !1305 opened by Derek Foreman (derekf) xwayland: Fix assert with some parented windows https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1305 [XWayland]
13:32ukiran: pq, based on the protocol, how can we create an image_description based on the icc_profile ? wp_image_description_factory_icc_v1_interface:: Create()
14:06pq: ukiran, you mean how a client can create an ICC-based image description? Yes, with wp_image_description_creator_icc_v1.
14:06pq: after checking that it actually is advertised as supported
14:07pq: new_icc_creator request gives you a wp_image_description_creator_icc_v1
14:13wlb: weston Merge request !1306 opened by Derek Foreman (derekf) rdp: Mark the current mode as current https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1306 [RDP backend]
14:32wlb: weston/main: Daniel Stone * 20 commits https://gitlab.freedesktop.org/wayland/weston/compare/b7b0042777c66565d51d2cbc7d00e48c2595d9bd...4c63a128575e0676e60e66586eac701326eab474
14:32wlb: weston Merge request !1291 merged \o/ (Allow overlapping outputs https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1291)
15:09wlb: weston Merge request !1307 opened by Philipp Zabel (pH5) frontend: Add tls-cert and tls-key config options https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1307
15:12wlb: weston Merge request !1308 opened by Philipp Zabel (pH5) Extract weston_output_set_single_mode() from RDP, to share with VNC https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1308
15:16wlb: weston Merge request !1309 opened by Philipp Zabel (pH5) backend-x11: fix output repaint timing https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1309
15:17wlb: weston Merge request !1310 opened by Philipp Zabel (pH5) backend-pipewire: make sure to finish frames with timestamps in the past https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1310
15:19wlb: weston Merge request !1311 opened by Philipp Zabel (pH5) backend-rdp: make sure to finish frames with timestamps in the past https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1311
15:32wlb: weston Merge request !1289 merged \o/ (Fix surface/view handling for test-surface https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1289)
15:32wlb: weston/main: Daniel Stone * tests: Move surface mapping earlier in surface-shell https://gitlab.freedesktop.org/wayland/weston/commit/e61d15dd763c tests/weston-test.c
15:32wlb: weston/main: Daniel Stone * tests: Use weston_view_move_to_layer() https://gitlab.freedesktop.org/wayland/weston/commit/5b14a094e7a2 tests/weston-test.c
15:32wlb: weston/main: Daniel Stone * tests: Don't remap surfaces with NULL buffer https://gitlab.freedesktop.org/wayland/weston/commit/caac97be6aad tests/weston-test.c
15:32wlb: weston/main: Daniel Stone * tests: Check that test-surface unmaps on NULL https://gitlab.freedesktop.org/wayland/weston/commit/43cc77d4e963 tests/paint-node-test.c
15:33wlb: weston Merge request !1306 closed (rdp: Mark the current mode as current)
15:48wlb: weston Issue #758 closed \o/ (Weston 12 rdp can't star visual studio code (electron) https://gitlab.freedesktop.org/wayland/weston/-/issues/758)
15:48wlb: weston/main: Philipp Zabel * backend-rdp: extract weston_output_set_single_mode() https://gitlab.freedesktop.org/wayland/weston/commit/e58452d6be36 libweston/ backend-rdp/rdp.c compositor.c libweston-internal.h
15:48wlb: weston/main: Philipp Zabel * backend-vnc: use weston_output_set_single_mode() https://gitlab.freedesktop.org/wayland/weston/commit/04c29e6aaee4 libweston/backend-vnc/vnc.c
15:48wlb: weston Merge request !1308 merged \o/ (Extract weston_output_set_single_mode() from RDP, to share with VNC https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1308)
17:18wlb: wayland Issue #393 opened by Tim Chernykh (j3su5cr1st) Failed to start X Wayland: Directory "/tmp/.X11-unix" is not writable https://gitlab.freedesktop.org/wayland/wayland/-/issues/393
17:21wlb: wayland/main: Peter Hutterer * Add a triage-policies file for bugbot https://gitlab.freedesktop.org/wayland/wayland/commit/e3908eb36062 .triage-policies.yml
17:21wlb: wayland Merge request !327 merged \o/ (Add a triage-policies file for bugbot https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/327)
17:26wlb: wayland Issue #393 closed \o/ (Failed to start X Wayland: Directory "/tmp/.X11-unix" is not writable https://gitlab.freedesktop.org/wayland/wayland/-/issues/393)
17:28emersion: seems to work
20:11Ishq: pq: it's because it directly hooks into libinput and doesn't rely on wayland, that said, I haven't given it significant mileage under wayland...(https://github.com/DolceTriade/gesturers/tree/master). It's worked great for the last few years, but given how everything was moving to wayland, I figure I'd port it over so I could use it on wayland
20:13Ishq: (specifically: https://github.com/DolceTriade/gesturers/blob/master/src/main.rs#L48-L61)
20:56vyivel: does https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/82#note_1274459 mean https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/151 was incorrect?
20:59jadahl: vyivel: hmm, true, part of the removed "meaning" should be morphed into the earlier paragraph
21:01vyivel: that sounds like it would require a version bump
21:02jadahl: why?
21:03jadahl: !151 attempted to deduplicate, but missed part of it
21:07vyivel: a compositor which implements the latest xdg-shell.xml has full rights to kill a client which tries to create a grabbing popup on top of a non-grabbing one
21:07vyivel: if the client wants to do that, it must be sure the compositor actually supports this case
21:07jadahl: !151 didn't change anything, so no it doesn't
21:24vyivel: weston and smithay don't seem to allow that fwiw
21:29vyivel: "xdg_popup was not created on the topmost popup"
21:49wlb: wayland-protocols Merge request !236 opened by Kirill Primak (vyivel) xdg-shell: clarify parent requirements for grabbing popups https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/236
21:58_DOOM_: Is it possible to create a library using some wayland protocols generated with wayland-scanner