00:13 kennylevinsen: danieldg: at least in wlroots' wlr_scene, there are no checks - the surface and the output transforms just cancel out during rendering
00:17 danieldg: I assume somewhere in the rendering pipeline there's a check to see if it needs to actually do scaling
00:31 kennylevinsen: danieldg: No, textures are always rendered with a projection matrix - it is just sometimes a really boring matrix.
01:28 emersion: IOW: multiplications are cheaper than conditions
02:55 Nefsen402: We do actually use conditionals to compute the matrix because textures origin is bottom left while compositing origin is top left. It hurt my brain too much to write it without conditionals :P
05:20 RAOF: Hm. Is there any good overview of sync fences in DRM? EGL_ANDROID_native_fence_sync just defers to “the native fence sync object”.
05:21 RAOF: Particularly: is there any way to create a fence fd and then insert it into the command stream at a later point? This looks to be possible with the NV fence extensions, but was dropped in the KHR version?
05:36 Lihua: hi everyone,I would like to ask a question, I have made a Qt application and would like to write data to other applications (such as a text editor) via a button. The way it works now is: let this app not get focus, focus is always on the editor, when the button is clicked, the data is written to the clipboard, and then by simulating a keystroke, the data is written to the editor. But now in Wayland system, after Qt writes the clipboard data, when
05:36 Lihua: processing the data in Wayland, it will determine `dataDevice->client() == keys.focus.surface->client()` in many places, because the data is coming from the Qt application and the focus is in the editor, which leads to a lot of unexecuted places code.
05:36 Lihua: Would like to ask if there is a solution to handle this situation.
06:17 ascent12: RAOF: They split out the ability to wait on a fence (on the GPU) into its own extension: EGL_KHR_wait_sync
06:18 zzag: RAOF: https://gitlab.freedesktop.org/wayland/weston/-/blob/d9a80735686060096a3661f6eb285c3595e0bf47/clients/simple-dmabuf-egl.c#L940
06:45 RAOF: ascent12: Hm. I'm actually after the other way - the equivalent of eglFenceNV, which inserts the “signal when I'm reached” end of the fence into the command stream, rather than the “wait until fence is signalled” end of the fence (which is indeed EGL_KHR_wait_sync).
06:46 ascent12: RAOF: I think simply creating the EGLSync object adds a fence to the command stream.
06:47 RAOF: ascent12: Yes, it does, and I'd like it to not. :)
06:48 RAOF: Specifically, because I'm dealing with threads, I'd like to create the sync object first, ship it off to the rendering thread where it needs to be inserted into the command stream after rendering, and then wait for it somewhere else.
06:51 RAOF: I don't _think_ that's possible with EGL as is, but I'd be happy to manually poke at the drmSyncobj/sync-file API (as I understand that's the native fence object ANRDOID_native_fence_sync backs onto), but that particular bit of the DRM API is not well documented. At least that I can find!
07:09 ascent12: RAOF: found it https://www.kernel.org/doc/html/latest/gpu/drm-mm.html#drm-sync-objects
07:26 RAOF: Hm. It's not _entirely_ clear to me, but I _think_ that maybe what I want to do is possible.
07:30 ascent12: I think creating a sync object (drmSyncobjCreate) then exporting an fd (drmSyncobjExportSyncFile) in the first thread, then eglCreateSyncKHR(EGL_SYNC_NATIVE_FENCE_FD_ANDROID) with it on the render thread (after rendering commands), will do what you're trying to do.
07:34 RAOF: The trick would be that exporting to a sync file is documented to snapshot the state of the syncobj, so the sync file created in the first thread would have no fence in the syncobj and would never have a fence in the syncobj?
07:36 RAOF: So I think what I'd need to do is create the sync object, export _that_ to an fd in the first thread, then… stuff?
07:36 RAOF: There's probably a way :)
08:22 daniels: RAOF: what you’re after is a timeline syncobj. fences can’t be materialised until their work has actually been flushed to the kernel
08:49 kennylevinsen: Lihua: clipboard access is only allowed from focused surfaces. Depending on what the purpose of the application is, text input or clipboard manager protocols could be relevant.
09:01 deathmist: what makes libinput classify something as a touchscreen? I'm trying to make a uinput touchscreen but it's acting like a laptop touchpad with cap:pg etc instead of cap:t and such; source https://gitlab.com/deathmist/ubports-mir-vnc-server/-/commits/focal-input-fix/
10:26 pq: deathmist, https://wayland.freedesktop.org/libinput/doc/latest/device-configuration-via-udev.html#udev-device-type
11:03 heeen: should wl_output mode reflect screen transform?
11:04 heeen: would a compositor be correct in switching to e.g. 800,1280 when in a portrait configuration?
11:04 pq: mode is the video mode, so no, but also the mode is kinda... should not exist
11:05 pq: well, at least the non-current modes are useless
11:07 pq: the spec even has a note that it might be fake
11:08 heeen: should geometry reflect orientation?
11:09 pq: I would tend to say no, so it matches mode.
11:10 heeen: hrm
11:10 pq: whatever you want to use these for, it would be good to think if a different interface would be better
11:11 pq: these are one of the oldest parts of wayland.xml and the Wayland paradigm was not fully baked at that time.
11:11 heeen: "The compositor works in the 'compositor coordinate system' and an output corresponds to a rectangular area in that space that is actually visible. "
11:12 heeen: I am reading from this it should be transformed coordinates if the respective output is rotated
11:12 pq: in particular modes and geometry were added just because surely they must be useful for something, IIRC
11:12 pq: i.e. cargo culted from X11
11:13 pq: heeen, I think that sentence has no intention to imply anything about coordinate system orientations, it's just geometry (in math sense).
11:14 pq: but if everyone read it like that...
11:15 heeen: maybe I'll have to use xdg_output after all
11:16 pq: one could also understand that mode describes the framebuffer, physical width/height match the mode, and geometry.transform tells you (incomplete!) what the area in compositor coordinate system is.
11:32 hch12907: curious, why has wayland!188 ("Add connection buffer size control") stalled?
13:34 MrCooper: heeen: according to Xwayland code, wl_output does not adjust geometry to rotation, xdg_output does
13:39 deathmist: pq: thanks, udevadm info now shows it as ID_INPUT_TOUCHSCREEN=1 but it still otherwise shows up/behaves like a touchpad; here's a quick comparison of what libinput vs evtest see for "taps" and "tap moving" https://paste.c-net.org/0q27lvlgibvg
13:48 pq: deathmist, I have no idea, sorry
14:51 deathmist: one thing I haven't tried is bisecting libinput itself as the previous working ver was 1.6.3 which correctly shows the current code as creating cap:t device and such
14:53 deathmist: the "broken" libinput ver is 1.15.5
14:53 deathmist: on the old one I don't even need the udev rule as it was automatically given ID_INPUT_TOUCHSCREEN=1
14:55 deathmist: so I'm wondering if I'm missing something to make libinput autodetect the new uinput device a touchscreen without udev rules even
14:59 deathmist: mhm, debug-events --verbose says "tagged by udev as: Touchpad Touchscreen", "Internal or external? Please file a bug." followed by "device is a touchpad" on 1.15.5
15:00 deathmist: that's with the udev rule in place btw and udevadm info showing the expected result
15:04 kennylevinsen: deathmist: you're landing here: https://gitlab.freedesktop.org/libinput/libinput/-/blob/main/src/evdev.c?ref_type=heads#L2063
15:05 kennylevinsen: probably due to this: https://gitlab.freedesktop.org/libinput/libinput/-/blob/main/src/evdev.c?ref_type=heads#L2029
15:10 colemickens: Hi. With X11, I think that X itself can handle font discovery. With Wayland, most applications use freetype/fontconfig. I'm encountering an application that does /not/ use fontconfig. The author is currently hard-coding well known font dirs to search, but the distro I use does not use any such standard paths. I believe that it just configures fontconfig to know about the appropriate fonts. Is there an option for an application using
15:10 colemickens: a custom font renderer to do font discovery, other than just pulling in fontconfig for the discovery?
15:10 kennylevinsen: deathmist: Also, both versions you're testing are *ancient*. 1.6.3 is from 2017, 1.15.5 from 2020. Latest release is 1.24.0
15:11 deathmist: yeah I know, these are on Ubuntu Touch 16.04 and 20.04 respectively
15:11 deathmist: later this year UT is moving to 24.04, but those are the previous and current release respectively
15:13 kennylevinsen: well, no one will remember what source looked half a decade ago. :)
15:13 kennylevinsen: (and a few years late for upgrading away from 16.04, but that's another topic altogether)
15:14 deathmist: thanks for the pointers though, I'll see what I can figure out
15:19 kennylevinsen: colemickens: why not just use fontconfig? it is just a font discovery library.
15:19 colemickens: I wasn't sure, mostly. And I'm not the dev ;). But that more or less answers my question.
15:28 MrCooper: X's own font management APIs only cover non-antialiased bitmap fonts, fontconfig was created for anti-aliased text with X
15:51 deathmist: ok wow so I reverted all my input changes (which compiled but created a device libinput ignored) and it just works with the udev rule in place!
15:53 deathmist: now if only I can get udev to auto-tag it as touchscreen capable that would be awesome