11:33 JoshuaAshton: What is the "proper" way to recieve the xserver's idea of cursor position when writing an X11 Window Manager? Ideally I'd get feedback in the event loop. We've always been doing XQueryPointer whenever we go to vblank, but that sucks because it's a blocking call. I can't rely on MotionNotify because grabbing, I can't rely on XInput2 because grabbing... Maybe I should bite the bullet and try out libei -- my issue there is that this also
11:33 JoshuaAshton: needs to work nested, and fwir libei x dbus does not play nicely with nested compositors there.
11:34 JoshuaAshton: I also tried doing a grab window type thing but that also just broke things and fell apart. :/
11:34 JoshuaAshton: (This is for Gamescope's X11 window manager fwiw, which is why I am asking in #wayland :P)
15:32 roussinm: Following the issue from yesterday with the drm driver not using LINEAR as default. After backporting the patch to our kernel, now I was getting `failed to create gbm surface`... It fails to add the modifier to the plane here: https://gitlab.freedesktop.org/wayland/weston/-/blob/10.0.2/libweston/backend-drm/kms.c?ref_type=tags#L477, I commented the line out and rendering seems to
15:32 roussinm: work perfectly. mod-formats == 0 is linear I think? If so, 0 should be a valid value?
15:37 daniels: roussinm: mod->formats is a bitmask of the supported format _indices_
15:37 daniels: so if format 0 is supported, mod->formats will contain (1 << 0) i.e. 1
15:37 daniels: that sounds like you don't have a format_mod_supported() hook which returns TRUE for the desired format + DRM_FORMAT_MOD_LINEAR
15:40 roussinm: daniels: ohhh _indices_, so format_mod_supported is missing somewhere... ok thanks!
15:40 daniels: np :)
16:04 roussinm: daniels: found the missing format_mod_supported, and now I'm getting mod->formats: 0xfff, interesting. Don't know on what it maps on, but at least now it renders.
16:07 daniels: roussinm: the mod blob has a list of formats (index -> DRM_FORMAT_*), then a list of modifiers (bitmask -> format index), so 0xfff means that there are 11 formats which all support LINEAR
16:07 daniels: if you want to see what's going on, drm_info is a really good tool
16:10 wlb: wayland-protocols Issue #171 closed \o/ (Brainstorming: Optimizing for hardware planes https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/171)
16:34 JoshuaAshton: Is it wrong that I am looking at the XEyes source code... Seems like it waits for XInput2 RawMotion then calls XQueryPointer, which I guess that works
16:34 JoshuaAshton: Sucks that I can't just get regular XI_Motion and read the root_x etc from it
16:35 JoshuaAshton: x11 makes me upset
16:35 JoshuaAshton: :(
16:39 zzag: pq: emersion: can you please confirm that if a surface has WL_OUTPUT_TRANSFORM_90 transform, then the compositor has to rotate buffer damage **counter**clockwise?
16:41 emersion: t has to compensate for the output
16:41 emersion: so opposte
16:42 emersion: opposite
16:48 zzag: hmm, now I'm even more confused.. there are effectively 4 transforms
16:48 zzag: 1. compositor global space -> output buffer
16:48 zzag: 2. output buffer -> compositor global space
16:48 zzag: 3. wl_buffer -> wl_surface
16:48 zzag: 4. wl_surface -> wl_buffer
16:49 zzag: where should the compositor rotate clockwise and counterclockwise?
16:49 ManMower: istr this being helpful when I went down these rabbit holes in the past: https://www.gfxstrand.net/faith/projects/wayland/transforms/
16:54 ManMower: not really sure how to answer the "where should..." question, because I think that varies based on compositor design. maybe you want to convert surface damage (whether it's in surface or buffer coordinates) into global coordinates at the moment a commit/transaction is applied (pending state becomes current state)
16:55 zamundaaa[m]: The protocol says... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/OZWIbnZktdcpADWVRYjgjYOO>)
16:56 zzag: It makes sense for case 1 and 4
16:57 zzag: or is it vice versa?
16:57 zzag:is confused..
16:58 zamundaaa[m]: the described transform is output buffer -> global coordinate space
16:58 zamundaaa[m]: *surface buffer, not output
16:59 zzag: so cases 2 and 3?
17:00 zamundaaa[m]: 3 is used to construct 2, so yes
17:01 zzag: but then, shouldn't it be "apply to a buffer to compensate for the rotation"?
17:03 zamundaaa[m]: oh, with "output buffer" you mean the buffer used for compositing, right?
17:03 zzag: yes
17:04 zamundaaa[m]: The transform describes 1 and 3 then
17:07 zamundaaa[m]: <zamundaaa[m]> "the described transform is..." <- that was wrong, it describes surface -> output buffer
18:56 emersion: > @emersion (desperate for a break from Django)
18:56 emersion: oh yeah sub-surface hard questions is exaaaactly what i need daniels :D
18:56 daniels: I was so desperate that I ended up getting into the mechanics of fucking subsurfaces
18:56 daniels: hahaha
18:57 daniels: I'm missing a Christmas party in order to do a PostgreSQL upgrade :\
19:20 ManMower: sub surfaces are the best