01:51 <ezzieyguywuf> why is the pointer coordinates provided as a Fixed, which includes decimal precision? what does it mean for the pointer to be at a fraction of a pixel location?

01:51 <ezzieyguywuf> I was looking at e.g. wl_pointer::motion

01:53 <ezzieyguywuf> also why is it signed? what is a negative pixel?

01:54 <danieldg> ezzieyguywuf: it's useful for things like a drawing program where you can paint a circle centered between pixels

01:54 <danieldg> negative pixels are seen in drags when they go above and left of the top of the window

01:55 <danieldg> also with scaling - a position of 1.5 might actually be 3 real pixels with scale 2

04:45 <whot> kennylevinsen: https://github.com/whot/wev/ has tablet support

04:47 <whot> should probably move this to gitlab wayland, the wev on sourcehut appears unmaintained

04:50 <whot> latex: the huion drivers that were part of digimend become part of the hid-uclogic driver in the kernel, but that's the huion ones only. others will be part of some other drivers in the kernel, as aproppriate. mind you, digimend is effectively dead now and we're planning to add future device support to udev-hid-bpf instead, so if the device doesn't work with the current kernel then

04:50 <whot> please file an issue there

06:27 <wlb> weston Issue #1014 opened by Manik Shekhar (manikshekhar15) weston-screenshooter error, weston --debug already enabled https://gitlab.freedesktop.org/wayland/weston/-/issues/1014

07:31 <wlb> weston Issue #1014 closed \o/ (weston-screenshooter error, weston --debug already enabled https://gitlab.freedesktop.org/wayland/weston/-/issues/1014)

08:13 <MrCooper> whot: might it make sense to add wev to wayland-utils?

09:45 <kennylevinsen> whot: oooh, I was wondering if there would be a fork but I didn't find yours - unfortunately, distro packages still point to the sourcehut one

10:30 <emersion> +1 for moving to gitlab and/or importing it in wayland-utils

11:28 <wlb> wayland-protocols Merge request !388 opened by Chris Morgan (chris-morgan) Tablet documentation tweaks (especially tool button values) https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/388

11:55 <pq> whot, do you remember if anyone had a touchscreen input device emulator (uinput)?

11:56 <pq> hmm, just realized that such a thing could be combined with evdi to make it do both touch and screen.

11:57 <pq> or a kmsgrab hack what was it called

12:04 <kennylevinsen> not sure if anyone other than displaylink uses the evdi out-of-tree driver...

12:05 <kennylevinsen> but if it doesn't have to be *fully* emulated, at least in wlroots we can just create headless outputs that one can screencopy and create a window out of

12:05 <kennylevinsen> for touchscreen emulation purposes

12:11 <pq> displaylink uses evdi, but evdi itself is open, and it only loops the DRM FBs back to userspace

12:11 <pq> there is also a Qt app that shows the evdi "display"

12:13 <pq> but yeah, mirroring to vnc and manually laying a semi-transparent touch emulation window on top might work for Weston

12:28 <kennylevinsen> it doesn't loop back the fbs, it does a CPU copy to a user-provided buffer from the latched DRM FB :/

12:29 <pq> oh, yes.

12:30 <kennylevinsen> it's also racey and have broken vblank handling, but I only *just* reported that so we'll see

12:30 <pq> it's not efficient, but should be good enough for testing

12:31 <kennylevinsen> that's true

12:31 <pq> obvious reasons why it's not upstream :-)

12:32 <kennylevinsen> but evdi + a `DRM_EVDI_GRABPIX` client seems to give roughly the same as a headless output + screencopy client

12:33 <kennylevinsen> and seeing that touchpanels are a distinct display and touch digitizer, I wonder if that wouldn't be an easier/better approach

12:37 <pq> just need to be able to bind the two together, but it would be too easy to assume and an evdev device can only associate with a KMS output.

12:37 <pq> s/and/that/

12:38 <kennylevinsen> hmm, I'm not aware of there being any association other than perhaps a connector hint

12:39 <kennylevinsen> but I have a vague recollection of even that being deprecated - sway uses a heuristic on connector name

12:40 <pq> mostly compositor-specific, yeah

12:40 <pq> Weston uses an udev property on the input device to name the output which to bind to.

12:41 <pq> That used to be a libinput thing, but got deprecated or never well established.

12:41 <kennylevinsen> ah yeah, you mean that a particular compositor might be unwilling to logically map a touchscreen to a headless output?

12:41 <pq> yeah

12:41 <kennylevinsen> Fair enough yeah

12:42 <kennylevinsen> tbf, the tool could just screencopy a real connected display

12:42 <kennylevinsen> and associate with that

14:17 <ezzieyguywuf> danieldg: I'm not sure what "scaling" is can you point me to any documentation? also, does this mean I can't solely rely on the x-y coordinates to relate directly to the x-y position of the pixels (i.e. do I need to account for this "scaling" thing?)

14:18 <ezzieyguywuf> for context I'm working on a vulkan renderer, and I want to use the x-y location of the mouse to determine if an item in the vulkan scene has been clicked on. in order for this to work I have to know the actual x-y pixel coordinate of the pointer

14:22 <kennylevinsen> ezzieyguywuf: the coordinates are in logical pixels. If someone has an output (display) running with a 2x scale (so stuff is 2x larger), each logical pixel spans two physical pixels

14:22 <kennylevinsen> and by virtue of being fixed point, you can know the pointer position with much higher resolution than either logical or physical pixels

15:14 <ezzieyguywuf> "know the pointer position with much higher resolution" I'm struggling to understand what this resolution actually accomplishes though. how is it helpful for me to know that the pointer is partially into a pixel? and how is wayland able to even calculate that? in my mental model the pixel is the lowest physical unit of resolution, so I can't gr0k a fraction of a pixel

15:15 <ezzieyguywuf> "the coordinates are in logical pixels" I see, this makes sense. so this means I _do_ need to account for scale for my implementation to work correctly.

15:20 <davidre> The mouse is an analog device

15:20 <davidre> so there is a difference between moving it from 1 to 2.5 or to 2.7

15:21 <davidre> but moving from 1.5 to 2.5 is the same as from 1 to 2

15:21 <davidre> it might matter for example for drag thresholds

15:59 <ezzieyguywuf> hm, ok I think I follow

18:09 <paulk> hi folks, currently looking at multi-device support in the drm backend

18:09 <paulk> (as-in multi card nodes)

18:10 <paulk> There's a backend->drm pointer that's used all around and sometimes duplicated calls using backend->kms_list

18:10 <paulk> the issue I'm having is essentially that atomic commit fails when the drm device device is specified as additional

18:11 <paulk> and works when specified via --drm-device

18:11 <paulk> ultimately my goal here is to implement mirror mode across drm devices from two different cards

18:12 <paulk> so would it be welcome to have some refactoring to remove backend->drm

18:12 <paulk> and to always use the list instead?

18:12 <paulk> and also, is anyone working on this currently?

18:14 <paulk> there's also backend->gbm that should be moved to the drm device

18:24 <daniels> paulk: it's mostly mol who worked on that iirc, or was it pH5?