16:20 bitblt: does the wayland protocol dictates the use of logical coordinates, and if they should be integer or fractional?
16:21 linkmauve: bitblt, pixels are always spaced by integers, but you have protocols such as wl_viewporter which let you scale a given buffer to an almost arbitrary scale and crop.
16:22 linkmauve: For input, clients always receive logical coordinates yes.
16:24 bitblt: yes, thats why I'm asking this. It is obvious that when dealing with buffers (to be presented on screen) the dimensions will be in integer pixels that must be in the same space as the resolution of the screen
16:24 bitblt: but when doing things such as fractional scaling, the 'logical' space may be fractional too in order to correctly map to the physical resolutions
16:25 bitblt: I see that in wlroots, the logical positions and dimensions are expressed with integers and this seems wrong
16:26 bitblt: so either this is a wlroots implementation problems, or the wayland spec dictates the use of integers for the logical coordinate system and wlroots adheres to that
16:27 emersion: all surface sizes etc are integers in logical coords
16:27 emersion: almost everything on the wire is logical coords, and almost everything is integers
16:28 bitblt: emersion: yes, this is my question, is it dictated by the spec that they should be, or its a choice in wlroots implementation?
16:28 emersion: exceptions: when creating a new buffer the size is in buffer-local coords, xdg-output and wl_output position are in layout coords
16:28 emersion: and input events are in general wl_fixed
16:28 emersion: it's spec'ed in the protocol
16:30 bitblt: buffer-local coords make sense to be in integers (its a pixel buffer with discrete pixels), xdg-output and wl_output and in general layout coords do not make sense to be integers, especially now that the fractional scale protocol exists
16:32 bitblt: let me give a specific example: in wlroots here: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/types/scene/wlr_scene.c?ref_type=heads#L2029 the logical render_data width is calculated from the real output resolution and the scale factor
16:33 bitblt: in my setup which is a laptop with resolution 2560x1600 and a scale factor of 1.75, this results in a logical resolution of 1462x914 which is way different from the 1462.8571x914.2457 that it should be
16:34 bitblt: so further calculations based on these truncated logical dimensions will be off
16:35 bitblt: if you take 1462*1.75=2558.5 and 914*1.75=1599.5
16:37 bitblt: even with rounding, you cannot infer the physical resolution correctly, so I thought that in general logical space coordinates/dimensions should be fractional for this to work correctly
16:41 vyivel: hot take setting a scale such that logical size is fractional shouldn't be allowed
16:42 bitblt: the problem is that logical sizes are everywhere, every window can result to a a fractional logical scale depending on its dimensions
16:43 vyivel: no it can't
16:43 vyivel: logical sizes of windows (surfaces) are always integer
16:44 vyivel: you're probably thinking about per-output physical sizes
16:47 bitblt: that means that each wayland client should get a slightly different scale value from the compositor, in order for it to have proper buffer size that matches its logical size * scale?
17:35 zamundaaa[m]: <vyivel> "hot take setting a scale such..." <- That doesn't work in practice
17:35 zamundaaa[m]: bitblt: see https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/149 for a proper solution of that problem
17:54 bitblt: zamundaaa: it seems that you have done plenty of work in kwin as a poc for the fractional scale v2 protocol
17:55 bitblt: I think this might be the solution to this too: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3793
20:32 wlb: wayland Merge request !460 opened by Rahul Sandhu (nvraxn) server: wl_client: introduce method for getting client security context https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/460
22:44 wlb: wayland Merge request !461 opened by Simon Ser (emersion) scanner: use separate guards for validator functions https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/461