05:28Company: my TigerLake doesn't get the float16 formats in Vulkan - WAYLAND_DEBUG says they're not advertised in the wl_drm format list
05:28Company: is that a mesa bug? a mutter bug? an intel bug?
05:29Company: wl_shm lists them
06:14wlb: weston/main: Sergio Gómez * clients: Replace 'confine' client to showcase pointer constraints in general https://gitlab.freedesktop.org/wayland/weston/commit/03aeb4bd836c clients/ constraints.c meson.build confine.c
06:14wlb: weston Merge request !1164 merged \o/ (Clients: Replace 'confine' client to showcase pointer constraints in general https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1164)
06:14DodoGTA: Is it possible to prevent weird mouse position jumps when relocking the pointer?
07:38MrCooper: Company: can you pastebin the output of wayland-info?
07:45MrCooper: FWIW though, I don't get any float formats advertised by wl_drm either, but vulkaninfo does list FORMAT_R16G16B16A16_SFLOAT for VK_KHR_wayland_surface; presumably zwp_linux_dmabuf_v1 is used
07:45MrCooper: (with ADL-P)
08:17Company: MrCooper: https://gitlab.gnome.org/-/snippets/5850 wayland-info
08:17Company: MrCooper: https://gitlab.gnome.org/-/snippets/5851 - WAYLAND_DEBUG for gtk-demo with Vulkan
08:24MrCooper: wayland-info is identical to mine WRT formats
08:25MrCooper: smells like a Mesa Vulkan driver issue to me
08:47MrCooper: Company: actually I can reproduce with Mesa 23.1, looks like it's been fixed on the main branch since then
08:49rahl: Do any of the libinput devs hang out here? I'd rather help to fix/improve my touchpad config for the community, rather than e.g. installing synaptic (assuming that would fix the issue)
08:52pq: rahl, yes, they do, e.g. whot, but timezones.
08:53wlb: weston Merge request !1274 opened by Philipp Zabel (pH5) Draft: backend-vnc: use weston_region_global_to_output https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1274
08:53pq: rahl, I suppose filing a libinput bug to ask would be much harder to miss than IRC.
08:54pq: rahl, one thing coming to my mind is whether that input device node is tagged correctly by udev.
08:56pq: rahl, https://wayland.freedesktop.org/libinput/doc/latest/device-configuration-via-udev.html#udev-device-type
08:57Company: MrCooper: that's pretty much exactly what I wanted to hear
08:57Company: thx
09:00MrCooper: no worries, now trying to find out what fixed it, to see if it can be backported to 23.1
09:09rahl: pq: timezones indeed. cheers - will check the link
09:09rahl: a bug report is the right next move
09:55rahl: pq: When you say "tagged correctly", is there a specific udev property you're thinking of?
09:55rahl: This is the output from udevadm info: https://termbin.com/34s2
09:55pq: rahl, the props are listed in that link
09:56rahl: The only thing that stands out to me, as with libinputs output, are the dimensions
09:56rahl: pq: It seems correctly recognised as a touchpad at least
09:56pq: that info looks fine to me
09:57rahl: even the width/height?
09:57pq: it's set - it's only about scaling the coordinates
09:57pq: maybe a wrong number, but not zero and not huge
09:57rahl: ah, ok
09:58pq: maybe it's about which evdev events the devide node claims to be able to emit, then
09:58pq: I'm just guessing here.
09:59rahl: How might I check your hypothesis?
09:59pq: there are tools, but I forget...
10:00rahl: no worries, I'll have a read around. Appreciated
10:00rahl: I'm now looking into udev to see if there's a way to probe the raw device. I'd read somewhere and tried `hexdump /dev/input/eventX` and got nothing at all
10:00pq: https://wayland.freedesktop.org/libinput/doc/latest/tools.html might be a start
10:00pq: that is concerning, yeah
10:02pq: well, it's possible that something already opened the device and took exclusive access to it, so I'm not sure if you'd get a permission denied in that case or just silence.
10:03rahl: Cheers for the link - checking
10:04rahl: I at least know the touchpad can work, as the originally installed Pop!_os behaved fine
10:08rahl: How can I test the keyboard de/activate function keys? Like the one for the touchpad.
10:08rahl: That's ACPI stuff right?
10:09pq: might be, I dunno
10:09rahl: Also, as of yesterday, list-devices shows the touchpad, measure gets no input, debug-events gets no input
10:09rahl: pq: ack, np
10:15MrCooper: Company: it's https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20234
10:16MrCooper: emersion: ^ might backporting that to 23.1 make sense?
10:18emersion: i don't think so, it's not a bugfix, it's a new feature
13:18emersion: jadahl: can you explain the use-case with the compositor denying the security context altogether?
13:18emersion: i'm not sure i'm understanding properly in which situation that'd happen
13:22jadahl: emersion: denying sockets given app IDs is one, sanity checking metadata so the compositor knows it can handle it properly could be another, but I guess it's more about theoretical use cases with a trivial future proofing of the protocol
13:23emersion: ideally the sandbox engine would not create sockets if the app is not allowed to do Wayland
13:23jadahl: for example if someone tries to use "flatpak" without all the flatpak metadata being there, it'd be an error that is hard to report atm
13:23emersion: if the metadata is incorrect per the engine, maybe send a protocol error?
13:23jadahl: that's a good point
13:23jadahl: (protocol error)
13:24jadahl: maybe an error enum for that is enough
13:24jadahl: an 'invalid_data' or something
13:26emersion: if it turns out we really need a done event, it can easily be added later
13:27emersion: added that error
13:28jadahl: sure
13:35jadahl: one problem with using an error is that the sandbox launcher must run indefinitely to discover, as disconnecting means it looses it
13:36jadahl: but maybe it doesn't matter, if validation fails, it'll be noticable anyway, eventually
13:36emersion: validation would happen synchronously no?
13:36emersion: flatpak does a wl_display_roundtrip() to make sure the request has been received by the compositor
13:36jadahl: no, we try hard to avoid any sinc i/o on the main thread where wayland happens
13:37jadahl: *sync
13:37emersion: i mean, synchronously when handling the commit request
13:37emersion: which would be enough for wl_display_roundtrip() to catch the error
13:37jadahl: validation would mean checking if the instance ID is actually there, for example
13:38emersion: ok
13:38jadahl: so it'd be commit() -> do file I/O async -> on_finished() { accept(); }
13:38emersion: i'm not sure this edge case is worth the protocol addition
13:38jadahl: so failure would not be detected until the app tries to connec
13:39swick[m]: I'm not sure second guessing what the client provides makes sense at all
13:39jadahl: yea, it's a bit unnecessary perhaps, the only benifit I see is the sandbox launcher knowing it'll fail, compared to the sandbox app failing
15:51wlb: weston/main: Philipp Zabel * backend-rdp: bring back shadow_surface image https://gitlab.freedesktop.org/wayland/weston/commit/e0c7fd1586ab libweston/backend-rdp/ rdp.c rdp.h
15:51wlb: weston/main: Philipp Zabel * backend-rdp: move code to prepare for GL renderer support https://gitlab.freedesktop.org/wayland/weston/commit/17d7353b36a5 libweston/backend-rdp/rdp.c
15:51wlb: weston/main: Philipp Zabel * backend-rdp: add pixel format info array https://gitlab.freedesktop.org/wayland/weston/commit/dbe5b5376683 libweston/backend-rdp/ meson.build rdp.c rdp.h
15:51wlb: weston/main: Philipp Zabel * backend-rdp: GL renderer support https://gitlab.freedesktop.org/wayland/weston/commit/ca1f6936c40e libweston/backend-rdp/rdp.c
15:51wlb: weston Merge request !1108 merged \o/ (backend-rdp: GL renderer support https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1108)
18:23rahl: Looking at this, it seems my issue is similar/the same, i.e. a kernel bug, which is either cantfix or wontfix from perspectiive of libinput devs https://gitlab.freedesktop.org/libinput/libinput/-/issues/592
18:23rahl: Does that mean I should be aiming at opening a bug report instead directly with the linux kernel devs?
18:26rahl: Hmm, then again, I know the device can work on *nix, so it can't strictly be a kernel bug.