00:27Consolatis: I'd strictly differentiate between the compositor and the desktop environment though. In some cases a desktop environment also provides the compositor but in other cases that is not true.
00:28Consolatis: which btw is an issue for some specific cases like for example having an up-to-date keyboard layout indicator in a panel without having keyboard focus
07:55KarenTheDorf: Is it normal for a compositor to need write access to wl_shm buffers? (I noticed kwin has a fast path if they have SEAL_SHRINK, so I thought, I know, I'll try adding SEAL_FUTURE_WRITE too, and that went boom)
07:57emersion: wl_shm buffers may be written to for some use-cases, e.g. screen capture
07:58KarenTheDorf: True, I guess I should specifically say that it's a buffer being used to back a wl_surface. So in a general case absolutely because I could use a buffer and ask the compositor to fill it with data.
07:59emersion: right, the problem is that the compositor doesn't know up-front what the buffer will be used for
07:59emersion: so kind-of needs to assume it can be used for any usage
08:00KarenTheDorf: Right, that makes sense. It won't know my use case at wl_shm_pool_create_buffer time. sure, I know it will be client->server only, but the server doesn't. Thanks.
09:59DonAlex: garnacho, I hear you are someone who knows how to allocate touch inputs to external monitors on Wayland?
10:02emersion: it depends on your compositor
10:02emersion: are you using GNOME, KDE, Sway, …?
10:02DonAlex: Well Gnome 3. so ?
10:02DonAlex: v46
10:02emersion: i think you can do it in settings
10:02DonAlex: I can't see anything there?
10:03garnacho: DonAlex: hey
10:04garnacho: yeah, touchscreen mapping to monitors is meant to be automagic, there's a GSetting underneath though
10:04garnacho: it's drawing tablets which do offer the full mapping options
10:04DonAlex: I mean only mouse and touchpad but that is for the laptop I know the touch inputs are detected because if I touch the external display it moved the mouse on my primary display
10:05garnacho: DonAlex: the mouse moving doesn't sound like a wayland session, though...
10:05DonAlex: So which gsetting should I look at? I am familar with using dconf
10:06DonAlex: Well the display is 'extended' in gnome. .but the touch movement is translated to the primary display.
10:08DonAlex: https://imgur.com/a/gnome-wayland-display-settings-o6TtQlq
10:11DonAlex: I mean I looked at this. But seems it is not wayland specific?
10:11DonAlex: https://who-t.blogspot.com/2024/03/enforcing-touchscreen-mapping-in-gnome.html
10:15garnacho: DonAlex: you'd need something like `gsettings set org.gnome.desktop.peripherals:/org/gnome/desktop/peripherals/touchscreens/VID:PID output "['VENDOR', 'PRODUCT', 'MODEL']" `, but that blogpost does indeed explain more in detail.
10:16DonAlex: Yeah.. I tried that.. but it came back saying it had no schema ?
10:19garnacho: DonAlex: I typoed mine, but whot did not. The schema should be "org.gnome.desktop.peripherals.touchscreen", the first piece of info right after "gsettings set"
10:20garnacho: that relocatable schema is defined at /usr/share/glib-2.0/schemas/org.gnome.desktop.peripherals.gschema.xml
10:21DonAlex: hmm lemme check
10:26DonAlex: Well it is correct as far asI can tell
10:26DonAlex: https://imgur.com/a/external-touchscreen-settings-gnome-wayland-mgOnJCQ
10:28garnacho: DonAlex: ah, in dconf-editor, nevermind that. It doesn't play well with relocatable schemas
10:28DonAlex: Oh?
10:28DonAlex: well I added it via gsettings though
10:30DonAlex: gsettings list-recursively org.gnome.desktop.peripherals.touchscreen:/org/gnome/desktop/peripherals/touchscreens/27c0:0859/
10:30DonAlex: org.gnome.desktop.peripherals.touchscreen output ['XKY', 'Display', 'demoset-1']
10:31garnacho: yeah, `gsettings get org.gnome.desktop.peripherals.touchscreen:/org/gnome/desktop/peripherals/touchscreens/27c0:0859 output` should tell the truth
10:32garnacho: if you're sure that's the VID/PID of the touchscreen input device, it should work as far as I can see...
10:33DonAlex: Same key
10:33DonAlex: `gsettings get org.gnome.desktop.peripherals.touchscreen:/org/gnome/desktop/peripherals/touchscreens/27c0:0859 output
10:33DonAlex: ['XKY', 'Display', 'demoset-1']
10:34DonAlex: Yup pretty sure that is correct Bus 001 Device 007: ID 27c0:0859 Cadwell Laboratories, Inc. TouchScreen
10:41garnacho: DonAlex: that sounds like bug territory, might also be interesting to find out why it didn't get automatically mapped to the right output.
10:41garnacho: I don't have an external touchscreen, but will be testing multimonitor...
10:42DonAlex: Well quite.. Could just be my bad luck.. But then again it is a USB powered monitor as well so maybe that confuses it ?
10:42kennylevinsen: garnacho: What does GNOME use as heuristic to associate the digitizer with the display panel?
10:42DonAlex: Well this one one is super cheap but nice.. light USB powered comes with it's own kickstand
10:43DonAlex: https://www.amazon.co.uk/dp/B0C1NLK5SX for anyone interested
10:44kennylevinsen: The well-known ZFTVNIE brand
10:45DonAlex: Is that sarcasm ? ;)
10:47kennylevinsen: yes, amazon drop-shippers just hammer on the keyboard to create their continously replaced throwaway brand-names
10:48DonAlex: Fairy nuff.
10:49garnacho: kennylevinsen: the most relevant for touchscreens is based on reported sizes in millimeters, from the absolute coords input device and edid. There's others through libwacom, for the devices supported there.
10:50DonAlex: libwacom ? Hmmmm
10:52garnacho: cheap brands have a tendency to blatantly lie in those, so perhaps the GSettings escape hatch is being well used here
10:54garnacho: DonAlex: is the device connected via a single cable? I wonder if it's sensitive to the connection order
10:55DonAlex: Well no. one HDMI and one USB. I can do USB video but my laptop does not support it. FWIW it does show two devices in libinput. https://pastebin.com/Zxd9iWVL
10:58garnacho: "Capabilities: pointer " in the second? interesting...
10:58garnacho: might be worth checking which of both devices gets triggered on touch input...
11:02DonAlex: Hang on just ran libinput debug-gui Will upload it so you can see the behaviour/
11:15DonAlex: garnacho, Here you go. If it makes and sense. Not sure why the touchpad moves on the external display but oh well https://vimeo.com/946148458
11:34DonAlex: oh that is kinda cool. Libinput shows how many fingers are touching and in what order.
11:35DonAlex: Anyway, lunchtime here atm. So back in about an hour
11:55garnacho: DonAlex: plain text output from "libinput debug-events" might be clearer :). I forget the libinput debug-gui feedback all the time, and can't easily check on silverblue...
11:55garnacho: if the output lines start with "event15", that'd be the wrong device
12:13wlb: weston Merge request !1515 opened by Alexandros Frantzis (afrantzis) clients/simple-egl: Allow exercising EGL_EXT_present_opaque https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1515
12:43YaLTeR[m]: Is it intended when a client acks a configure dropping the resizing state but then doesn't commit, if it doesn't have anything else it wants to commit?
12:43YaLTeR[m]: Resulting in the toplevel kind of hanging with the resizing state for a while
12:50DonAlex: garnacho, Ok well here is a pastbin of that dragging a finger and touch up and down. https://pastebin.com/1qr8tLaw
12:57YaLTeR[m]: How do you tell if the client committed new size after a minute in response to the last configure that dropped the resizing state, or just because it decided to change size on its own?
12:58YaLTeR[m]: (in the former case the client should move on screen if it was a top-left resize, in the latter case the client should not move)
12:58emersion: acks are double-buffered
12:59emersion: IOW, acks have no effect until the next commit
12:59garnacho: DonAlex: thanks, that looks correct... perhaps it's time for a Mutter bug report
13:00DonAlex: Hmm ok
13:02YaLTeR[m]: emersion: yeah exactly, and I'm seeing Firefox and Chromium just not commit their toplevel after acking a configure that dropped the resizing state (but did not request a new size). Which means that if they commit a different size in a minute, I don't know if that's their response to the last resizing commit, or if that's an unrelated new size
13:03emersion: are you describing a Firefox bug then?
13:03jadahl: sounds like it
13:03YaLTeR[m]: I'm asking if that's a firefox and chromium bug, or if it's expected behavior that I should figure out a way to deal with
13:05jadahl: YaLTeR[m]: fwiw: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7139
13:05jadahl: maybe thats the firefox bug
13:05YaLTeR[m]: This sounds like that I want from firefox/chromium here
13:06YaLTeR[m]: s/that/what
13:06jadahl: firefox uses gtk3, so maybe that gtk MR fixes the firefox issue, I dunno
13:06YaLTeR[m]: Electron apps also do this. So uh
13:07jadahl: an ozone-wayland bug then?
13:09YaLTeR[m]: I'm just thinking that since electron does this, I need at least some working around in the compositor because it ain't getting fixed for a while in apps
13:13mclasen: jadahl: should I merge that gtk3 mr ? let me know
13:16jadahl: mclasen: you did a month ago
13:16mclasen: ah, well. Just need to get a release out
13:19jadahl: yea
14:06pq: Sounds like firefox and chromium might be sending their acks from configure event handlers instead of from the drawing path. That might be nice to fix, too.
14:20kennylevinsen: relying on paint to commit is fine assuming the configure path can schedule a forced paint...
14:21jadahl: kennylevinsen: on gtk3 I just scheduled an empty paint just for the commit
15:36Max1: YaLTeR: regarding Chromium not committing after ack'ing a configure, can you please file a bug at https://issues.chromium.org/ and ping me about it?
15:37YaLTeR[m]: Hmm, alright, I'll see
15:37Max1: Thanks!
15:50ifreund: YaLTeR[m], Max1: perhaps related https://codeberg.org/river/river/issues/1020
15:51YaLTeR[m]: idk if related to this specifically, but I did notice upon creating a new window chromium is a bit glitched out until the next configure
15:52Max1: There have been a few changes recently which might be related to this, it might make sense to grab the latest build from https://download-chromium.appspot.com/ and test with that
17:02YaLTeR[m]: Max (usually off on Fridays): https://issues.chromium.org/issues/340500574
17:02YaLTeR[m]: oh that log got screwed up
17:35codecolla: Hi, for brand new xdg protocol, generative IAs are no longer useful, so I drop issues here :
17:36codecolla: For compilation : `pkg-config --variable=wayland_scanner wayland-scanner` client-header `pkg-config wayland-protocols --variable=pkgdatadir`/stable/xdg-shell/xdg-shell.xml xdg-shell-client-protocol.h
17:36codecolla: pkg-config wayland-protocols --variable=pkgdatadir gives nothing. Any idea why?
17:39bl4ckb0ne: have generative ia ever been useful?
17:39bl4ckb0ne: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/tinywl/Makefile tinywl does it fairly easily
17:40codecolla: Yes for what is well known, but wrongly documented...
17:41codecolla: I took the hole https://github.com/emersion/hello-wayland/blob/opengl-cube you first sent to me, I'm on this compil issue
17:42codecolla: I'm jumping on tinywl as you sent to me, thx
17:42bl4ckb0ne: hm i do get compilation issues as well
17:42codecolla: same?
17:43bl4ckb0ne: shell escape and missing dep
18:29codecolla: In both cases /stable/xdg-shell/xdg-shell.xml might be missing ls: cannot access '/stable/xdg-shell/xdg-shell.xml': No such file or directory
18:31bl4ckb0ne: did you replace the `pkgXXX` with $(shell pkgXXX)` like tinywl does
18:31codecolla: Ho, once again WAYLAND_PROTOCOLS=$(shell pkg-config --variable=pkgdatadir wayland-protocols) is void
18:31codecolla: pkg-config --variable=pkgdatadir wayland-protocols gives nothing in shell
18:31vyivel: do you have wayland-protocols installed
18:31bl4ckb0ne: do you have the wayland-protocols installed
18:31vyivel: lel
18:32bl4ckb0ne: kek vyivel
18:32codecolla: Im checking
18:33codecolla: Only wayland-protocols-devel.noarch on dnf, that's it?
18:34bl4ckb0ne: i think so
18:35bl4ckb0ne: https://fedora.pkgs.org/40/fedora-x86_64/wayland-protocols-devel-1.34-1.fc40.noarch.rpm.html it has the pc file
18:38codecolla: Thx, one step ahead, I now have fatal error: wlr/backend.h: No such file or directory but I'm gonna switch back to opengl-cube
18:40wlb: weston Merge request !1516 opened by Jonas Ådahl (jadahl) terminal: Avoid too large character grid when resized https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1516 [Clients]
18:43bl4ckb0ne: thats a wlroots file
18:43bl4ckb0ne: you dont need it for clients
18:46codecolla: I face other issues on the wayland_egl : undefined reference to symbol 'sqrtf@@GLIBC_2.2.5
18:47vyivel: add -lm somewhere in Makefile
18:47codecolla: yeah
18:55codecolla: CGLM_FLAGS = `pkg-config cglm --cflags --libs` -lm worked