01:51ezzieyguywuf: 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:51ezzieyguywuf: I was looking at e.g. wl_pointer::motion
01:53ezzieyguywuf: also why is it signed? what is a negative pixel?
01:54danieldg: ezzieyguywuf: it's useful for things like a drawing program where you can paint a circle centered between pixels
01:54danieldg: negative pixels are seen in drags when they go above and left of the top of the window
01:55danieldg: also with scaling - a position of 1.5 might actually be 3 real pixels with scale 2
04:45whot: kennylevinsen: https://github.com/whot/wev/ has tablet support
04:47whot: should probably move this to gitlab wayland, the wev on sourcehut appears unmaintained
04:50whot: 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:50whot: please file an issue there
06:27wlb: weston Issue #1014 opened by Manik Shekhar (manikshekhar15) weston-screenshooter error, weston --debug already enabled https://gitlab.freedesktop.org/wayland/weston/-/issues/1014
07:31wlb: weston Issue #1014 closed \o/ (weston-screenshooter error, weston --debug already enabled https://gitlab.freedesktop.org/wayland/weston/-/issues/1014)
08:13MrCooper: whot: might it make sense to add wev to wayland-utils?
09:45kennylevinsen: 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:30emersion: +1 for moving to gitlab and/or importing it in wayland-utils
11:28wlb: 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:55pq: whot, do you remember if anyone had a touchscreen input device emulator (uinput)?
11:56pq: hmm, just realized that such a thing could be combined with evdi to make it do both touch and screen.
11:57pq: or a kmsgrab hack what was it called
12:04kennylevinsen: not sure if anyone other than displaylink uses the evdi out-of-tree driver...
12:05kennylevinsen: 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:05kennylevinsen: for touchscreen emulation purposes
12:11pq: displaylink uses evdi, but evdi itself is open, and it only loops the DRM FBs back to userspace
12:11pq: there is also a Qt app that shows the evdi "display"
12:13pq: but yeah, mirroring to vnc and manually laying a semi-transparent touch emulation window on top might work for Weston
12:26kennylevinsen:looked into evdi recently to debug some issues, came out sad
12:28kennylevinsen: it doesn't loop back the fbs, it does a CPU copy to a user-provided buffer from the latched DRM FB :/
12:29pq: oh, yes.
12:30kennylevinsen: it's also racey and have broken vblank handling, but I only *just* reported that so we'll see
12:30pq: it's not efficient, but should be good enough for testing
12:31kennylevinsen: that's true
12:31pq: obvious reasons why it's not upstream :-)
12:32kennylevinsen: but evdi + a `DRM_EVDI_GRABPIX` client seems to give roughly the same as a headless output + screencopy client
12:33kennylevinsen: and seeing that touchpanels are a distinct display and touch digitizer, I wonder if that wouldn't be an easier/better approach
12:37pq: 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:37pq: s/and/that/
12:38kennylevinsen: hmm, I'm not aware of there being any association other than perhaps a connector hint
12:39kennylevinsen: but I have a vague recollection of even that being deprecated - sway uses a heuristic on connector name
12:40pq: mostly compositor-specific, yeah
12:40pq: Weston uses an udev property on the input device to name the output which to bind to.
12:41pq: That used to be a libinput thing, but got deprecated or never well established.
12:41kennylevinsen: ah yeah, you mean that a particular compositor might be unwilling to logically map a touchscreen to a headless output?
12:41pq: yeah
12:41kennylevinsen: Fair enough yeah
12:42kennylevinsen: tbf, the tool could just screencopy a real connected display
12:42kennylevinsen: and associate with that
14:17ezzieyguywuf: 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:18ezzieyguywuf: 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:22kennylevinsen: 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:22kennylevinsen: and by virtue of being fixed point, you can know the pointer position with much higher resolution than either logical or physical pixels
15:14ezzieyguywuf: "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:15ezzieyguywuf: "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:20davidre: The mouse is an analog device
15:20davidre: so there is a difference between moving it from 1 to 2.5 or to 2.7
15:21davidre: but moving from 1.5 to 2.5 is the same as from 1 to 2
15:21davidre: it might matter for example for drag thresholds
15:59ezzieyguywuf: hm, ok I think I follow
18:09paulk: hi folks, currently looking at multi-device support in the drm backend
18:09paulk: (as-in multi card nodes)
18:10paulk: There's a backend->drm pointer that's used all around and sometimes duplicated calls using backend->kms_list
18:10paulk: the issue I'm having is essentially that atomic commit fails when the drm device device is specified as additional
18:11paulk: and works when specified via --drm-device
18:11paulk: ultimately my goal here is to implement mirror mode across drm devices from two different cards
18:12paulk: so would it be welcome to have some refactoring to remove backend->drm
18:12paulk: and to always use the list instead?
18:12paulk: and also, is anyone working on this currently?
18:14paulk: there's also backend->gbm that should be moved to the drm device
18:24daniels: paulk: it's mostly mol who worked on that iirc, or was it pH5?