ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
rv1sr has quit [Ping timeout: 480 seconds]
aknot has quit [Ping timeout: 480 seconds]
aknot has joined #wayland
soreau has quit [Ping timeout: 480 seconds]
aknot has quit []
kenny has quit [Quit: WeeChat 4.1.2]
aknot has joined #wayland
kenny has joined #wayland
Company has quit [Quit: Leaving]
soreau has joined #wayland
aknot has quit []
aknot has joined #wayland
aswar002_ has quit []
aswar002 has joined #wayland
aknot has quit []
aknot has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
privacy has quit [Quit: Leaving]
glennk has quit [Ping timeout: 480 seconds]
Dami_Lu has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
aknot_ has joined #wayland
Leopold___ has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
aknot_ has quit [Ping timeout: 480 seconds]
aknot has quit [Ping timeout: 480 seconds]
lbia has quit [Quit: lbia]
suntory has joined #wayland
suntory_ has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
zvarde1988303206779191685 has quit [Quit: Ping timeout (120 seconds)]
zvarde1988303206779191685 has joined #wayland
privacy has joined #wayland
sima has joined #wayland
sevz17 has quit [Quit: Client quit]
roussinm has quit []
leon-anavi has joined #wayland
kts has joined #wayland
rgallaispou has quit [Quit: Leaving.]
Dami_Lu has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]
mtretter has joined #wayland
kts has quit [Quit: Konversation terminated!]
Dami_Lu has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
garnacho has joined #wayland
glennk has joined #wayland
mvlad has joined #wayland
rv1sr has joined #wayland
caveman has quit [Quit: caveman]
lbia has joined #wayland
Company has joined #wayland
privacy has quit [Quit: Leaving]
glennk has quit [Ping timeout: 480 seconds]
fossdd has quit [Read error: Connection reset by peer]
fossdd has joined #wayland
Dami_Lu has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
leon has joined #wayland
Dami_Lu has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
leon has quit []
leon-anavi has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
<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
<JoshuaAshton>
needs to work nested, and fwir libei x dbus does not play nicely with nested compositors there.
<JoshuaAshton>
I also tried doing a grab window type thing but that also just broke things and fell apart. :/
<JoshuaAshton>
(This is for Gamescope's X11 window manager fwiw, which is why I am asking in #wayland :P)
<roussinm>
work perfectly. mod-formats == 0 is linear I think? If so, 0 should be a valid value?
bodiccea has joined #wayland
<daniels>
roussinm: mod->formats is a bitmask of the supported format _indices_
<daniels>
so if format 0 is supported, mod->formats will contain (1 << 0) i.e. 1
<daniels>
that sounds like you don't have a format_mod_supported() hook which returns TRUE for the desired format + DRM_FORMAT_MOD_LINEAR
glennk has quit [Ping timeout: 480 seconds]
<roussinm>
daniels: ohhh _indices_, so format_mod_supported is missing somewhere... ok thanks!
<daniels>
np :)
AnuthaDev has joined #wayland
<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.
<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
<daniels>
if you want to see what's going on, drm_info is a really good tool
<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
<JoshuaAshton>
Sucks that I can't just get regular XI_Motion and read the root_x etc from it
<JoshuaAshton>
x11 makes me upset
<JoshuaAshton>
:(
glennk has joined #wayland
<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?
kts has quit [Quit: Leaving]
<emersion>
t has to compensate for the output
<emersion>
so opposte
<emersion>
opposite
kts has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
<zzag>
hmm, now I'm even more confused.. there are effectively 4 transforms
<zzag>
2. output buffer -> compositor global space
<zzag>
3. wl_buffer -> wl_surface
<zzag>
1. compositor global space -> output buffer
<zzag>
4. wl_surface -> wl_buffer
<zzag>
where should the compositor rotate clockwise and counterclockwise?
Guest11082 has quit [Remote host closed the connection]
<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)