ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
Elon_Satoshi has joined #wayland
pnowack has quit [Quit: pnowack]
dcz_ has quit [Ping timeout: 480 seconds]
<Elon_Satoshi>
How does mouse lock work in wayland?
<Elon_Satoshi>
Games that lock the mouse, such as minetest or xonotic, don't work properly in cage, but they do in sway
<Elon_Satoshi>
Is there a fork of cage with mouse lock enabled?
<Elon_Satoshi>
Or is it more complicated than that?
columbarius has quit [Ping timeout: 480 seconds]
<soreau>
Elon_Satoshi: You can check what protocols are supported in a compositor by running any native client with WAYLAND_DEBUG set and grep stderr for 'global' or 'zwp_pointer_constraints_v1'. If cage advertises support but it's not working, it could be a bug in the cage implementation of the protocol
<soreau>
I would guess cage simply doesn't support the protocol and it would need to be implemented in cage
JonasTripps has joined #wayland
<soreau>
that said, you can make wayfire behave like cage and it does support this protocol..
JonasTripps has quit [autokilled: This host violated network policy. Mail support@oftc.net if you feel this in error. (2021-11-16 01:40:38)]
<Elon_Satoshi>
soreau: very interesting, I'll look into wayfire!
<Elon_Satoshi>
soreau: How would I configure wayfire to run like cage?
<soreau>
Elon_Satoshi: we can help you with that in #wayfire on libera chat
<Elon_Satoshi>
oh okay
c7s has quit [Ping timeout: 480 seconds]
danieldg has quit [Ping timeout: 480 seconds]
danieldg has joined #wayland
leon-p has joined #wayland
slattann has joined #wayland
cvmn has joined #wayland
Arnavion has quit [Remote host closed the connection]
Arnavion has joined #wayland
Elon_Satoshi has quit [Ping timeout: 480 seconds]
Elon_Satoshi has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
slattann has quit []
slattann has joined #wayland
hardening has joined #wayland
danvet has joined #wayland
jgrulich has joined #wayland
pnowack has joined #wayland
slattann has quit []
Elon_Satoshi has quit [Ping timeout: 480 seconds]
cvmn has quit [Ping timeout: 480 seconds]
novakane has joined #wayland
caveman has quit [Quit: caveman]
caveman has joined #wayland
slattann has joined #wayland
hill has joined #wayland
rasterman has joined #wayland
dcz_ has joined #wayland
tzimmermann has joined #wayland
<pq>
kennylevinsen, multiple wl_seats means multiple different libxkbcommon "contexts", right? Not feeding everything to the same xkbcommon context.
<pq>
DemiMarieObenour[m], the resize does not actually happen until your Wayland compositor forwards it to screen. When you get a new size from the client, why cannot you adapt the window position to the new size instead of the suggested size?
<pq>
DemiMarieObenour[m], and by resize I don't mean "user has finished resizing the window", but each step with some new size along the way.
<romangg>
pq: Would have thought only the states are different (per physical keyboard). context can be a single one.
<romangg>
"The xkb_context contains the keymap include paths, the log level and functions, and other general customizable administrativia."
<pq>
romangg, the difference is, are the physical keyboards in the same or separate wl_seats.
<pq>
separate wl_seats can simultaneously have separate keymaps for instance, which is not possible within a single wl_seat from client perspective.
<pq>
multiple physical keyboards in the same wl_seat are supposed to act as if you had just one physical keyboard.
<pq>
OTOH, physical keyboards in differen wl_seats are completely indepndent from each other.
<pq>
romangg, I also wrote "context" because I do not know what the right xkbcommon type is.
<pq>
looks like the struct I meant with "context" is xkb_state.
<pq>
hence, each wl_seat with keyboard capability needs its own xkb_state.
<pq>
pushing keyboard events from multiple wl_seat into the same xkb_state would be wrong.
mbalmer has quit [Remote host closed the connection]
mbalmer has joined #wayland
mbalmer has quit [Read error: Connection reset by peer]
<kennylevinsen>
pq: yup, you'd need an xkb_state per keyboard, which for a wayland client becomes per wl_seat.
mbalmer has joined #wayland
<romangg>
Well, if you can have multiple keyboards with different states/keymaps in the same seat is still not fully decided. I think you should be able to. But there were concerns why it's not doable on a technical level with the current protocol.
<kennylevinsen>
How is it not fully decided? wl_seat can only expose a single wl_keyboard, which can only communicate state changes to its own single instance. So, for a single seat, a given button is either held or is not, and is interpreted with a single keymap at a time.
<kennylevinsen>
communicating multiple keyboards require exposing multiple wl_keyboard instances, which either requires multiple wl_seats or a change to wl_seat to expose multiple wl_keyboards
<kennylevinsen>
yeah sure, wl_keyboard could also multiplex things like this, but potato tomato. Same result as multiple wl_keyboard, just a bit more duct-tapey.
<romangg>
I don't think it's the same thing. Having multiple wl_seat also implies having different surface focuses etc.
<kennylevinsen>
Multiple wl_seats have a different semantic meaning. Having wl_seat expose multiple wl_keyboard is what you're looking for. Making wl_keyboard multiplex its own events with logical keyboard source markers is in my opinion duct tape, as that's what object instances are for.
<romangg>
I don't know what's better. At the moment you can't have multiple wl_keyboards per wl_seat. swick, had you considered this instead of logical keyboards?
<kennylevinsen>
wl_seat::create_keyboard_listener that informs you of new keyboard IDs and wl_seat::create_keyboard(id) to get it. wl_seat::get_keyboard would get a "merged" keyboard like always, making it fully backwards compatible unlike the logical keyboard proposal.
<kennylevinsen>
(the logical keyboard proposal leads to inconsistent state if the multiplexing events are not understood by the client, making it backwards incompatible)
<kennylevinsen>
the backwards compatibility would very much be needed as no clients are ready to handle multiple keyboards on a seat
<kennylevinsen>
One could be tempted to think that it would have been simpler if the bare devices were just exposed directly from the beginning (myself included), but then hardware manufacturers throw you curveballs like composite keyboard devices where some keys are a different device...
fmuellner has quit [Remote host closed the connection]
<DemiMarieObenour[m]>
pq: Actually, the resize *does* happen sooner then that. My compositor is rootless, and its backend maps to safe subset of X11. If I understand the way resizing works in X11, my compositor doesn’t get notified until the X11 window manager has already redrawn its decorations. And my backend doesn’t support the synchronization features of EWMH.
<DemiMarieObenour[m]>
kennylevinsen: Are there *any* clients that handle multiple seats properly?
<emersion>
yes
fmuellner has joined #wayland
<emersion>
GTK does
<DemiMarieObenour[m]>
nice
<emersion>
some other do too
<emersion>
don't remember about Qt
<pq>
DemiMarieObenour[m], sounds like your Wayland compositor should do more when it received a wl_surface.commit on a top-level then: adjust both position and size, not merely size of the X11 window.
<pq>
DemiMarieObenour[m], or the very least set the X11 Window gravity to match the resizing.
<DemiMarieObenour[m]>
pq: interesting thought. I guess it can use a simple heuristic (“which side changed in the last configure?”) to know what to do motion-wize.
<pq>
DemiMarieObenour[m], why would you need such heuristic? xdg_toplevel.resize carries the resize edges explicitly.
<pq>
DemiMarieObenour[m], or, if the resize is started by the X11 WM and not the Wayland app, then the X11 WM knows which edge it wants to move, and could maybe be fixed to handle it if it doesn't.
<DemiMarieObenour[m]>
pq: resize is initiated by the XWM here
<swick>
kennylevinsen: I don't understand the backwards compatbile remark. interfaces are versioned and there is a reason why we *don't* want clients to use "merged" keyboard.
<emersion>
the compositor will need to de-duplicate double-press/release events anyways, because of libinput device groups
<swick>
if the compositor internally does some merging or not is not really relevant is it?
<swick>
if clients use a merged stream and there is keyboards which can trigger some weirdness in it then the existence of multiple keyboards at the protocol level doesn't help anyone
<swick>
anyway, I agree that having multiple wl_keyboards is cleaner than the logical keyboard stuff and if it deprecated the merged stream I would be fine with it
<swick>
can't force everyone to use the latest version of the protocol anyway
<emersion>
iirc blocked because of a disagreement with the flatpak folks?
<emersion>
i don't even remember
<swick>
is it?
<swick>
I think the main problem is about when the compositor can stop listening on the socket
<swick>
the flatpak process doesn't stay behind to clean up things so there needs to be a mechanism which somehow signals the compositor when the container goes down
<emersion>
ah, i think i stopped because it was becoming a bit too messy
<emersion>
with 2-3 different FDs
<emersion>
one for socket, one for ready, one for close…
<swick>
the dbus proposal suggests using pipes: send one end to the compositor, send the other to pid1 in the sandbox. when the sandbox dies the pipe closes
<emersion>
or something
<swick>
oh, ready, right
<swick>
the pidfd stuff is straight forward compared to that
<DemiMarieObenour[m]>
What are the options for status notifiers on Wayland? Is there an option that is compatible with Qubes OS’s sandboxing needs? That requires that all rendering be done in the qube.
<swick>
mhh, I still don't get the need for a ready pipe. "so that the listening socket *only* exists inside the container" why would that be important?
<DemiMarieObenour[m]>
SardemFF7: My understanding is that that makes the desktop environment responsible for rendering, which is a large attack surface
<SardemFF7>
since GNOME 3, at least back in the day, these icons are second-class citizen for backward compat, and applications are supposed to use persistent notifications (either the old https://specifications.freedesktop.org/notification-spec/latest/ or the newer GNotification from GIO/GLib)
pedro1___ has joined #wayland
pedro1___ has quit []
<emersion>
DemiMarieObenour[m]: not necessarily: on sway, the swaybar process will render
<emersion>
on GNOME the compositor does a lot of crazy rendering, but on other desktops that in general not the case
<SardemFF7>
yes it’s up to the DE, but with many limitations for the GNOME solution at least, since it’s just an icon and some text
<DemiMarieObenour[m]>
emersion: Swaybar is still a privileged process in Qubes OS
<SardemFF7>
emersion: I may be picky but DE != compositor :-)
<DemiMarieObenour[m]>
Right now the qube only sends a bitmap.
<emersion>
i chose "desktop" explicitly to avoid the DE/compositor debate
<DemiMarieObenour[m]>
SardemFF7: DE vs compositor doesn’t matter here. What matters is whether I can just have a VM send over an opaque bitmap to display.
<SardemFF7>
sure
<emersion>
ah, you meant that "DE" includes the DE helper clients. i just now realize that
<DemiMarieObenour[m]>
yup
<DemiMarieObenour[m]>
In fact it includes all Wayland clients
<SardemFF7>
np, I’m terrible at speaking
<DemiMarieObenour[m]>
specifically, Qubes OS does not consider the Wayland compositor to be a sufficient security boundary
<SardemFF7>
so you have a middle man, and can’t it proxy specific D-Bus interfaces to sanitize or whatever?
<SardemFF7>
s/man/something/
<pq>
emersion, thanks for me comments anyway. Did you at least see the sRGB EOTF graph? :-)
<emersion>
yes!
<emersion>
thanks for that
<emersion>
images and pictures help me a lot in general
<pq>
maybe I should write down that it's an Octave script...
<DemiMarieObenour[m]>
SardemFF7: Correct. Minimizing the complexity of the protocol is absolutely critical, as it directly impacts attack surface and the likelihood of a breach. The current protocol is almost entirely fixed-sized structs + Xen shared memory.
jgrulich has quit [Ping timeout: 480 seconds]
<SardemFF7>
the project I’m currently working on (paid job, don’t judge me ><) would probably give you (and many people here) a heart attack ^^'
<swick>
because i'd like to add the frame callback mechanism to just be removed in favor of a real scheduling protocol and the state committing replaced entirely with a transaction object
<kennylevinsen>
swick: I meant that it wasn't backwards compatible in that no client would be able to update without significant work, and many clients probably wouldn't do it anytime soon - even if the current solution has issues. That becomes a problem with interface-wide versioning where it's all-or-nothing...
<swick>
right, okay, that makes more sense to me
<kennylevinsen>
(arguably poorly worded on my part)
mbalmer_ has joined #wayland
mbalmer has quit [Read error: Connection reset by peer]
<romangg>
swick: I understood it to be a place to voice issues that should be reconsidered in a next protocol version, in particular things that can't be easily added to the current Wayland protocol.
<romangg>
Don't think it was meant only for pq to write notes. Otherwise sorry pq. :P
<romangg>
yea, I added the thing with the keyboards to it since you seemed to agree that the best possible way forward would be to allow multiple wl_keyboards under a wl_seat but that it might be difficult to get it into the current protocol.
<kennylevinsen>
well, I think it would be "relatively easy" (you know, for a core protocol change) *if* it's optional to use for clients. The implementation seems relatively obvious unless I'm missing something. Big question is the politics and whether we can get the compositor stakeholders on board.
zebrag has joined #wayland
thx_ has joined #wayland
<swick>
yeah, both multiple wl_keyboards or multiplexing in a single wl_keyboard are relatively easy at a protocol level
thx has quit [Remote host closed the connection]
thx_ has quit [Read error: Connection reset by peer]
thx has joined #wayland
slattann has joined #wayland
<DemiMarieObenour[m]>
<SardemFF7> "the project I’m currently..." <- can you talk about that project?
<SardemFF7>
I’m not sure to which extend, but let’s say it’s French C + Bash from 20+ years ago, “updated” by more French people 15+ years ago, with added Java for the fun, ported to 64bit CentOS 7 3+ years ago by another batch of French people, and some British people (= editing code mostly in French with French comments), the current team, watered down to 1 person, with added C++/Qt
<SardemFF7>
for another set of features and some C++/Boost for hardware abstraction
<SardemFF7>
(the C++ part is much more recent, and actually quite nice, and luckily weakly connected to the legacy code)
<SardemFF7>
and I am definitely not saying that the European Space Agency will make use of that project for the first launch of their next gen satellite launchers
<SardemFF7>
which is really scary
Elon_Satoshi has joined #wayland
tzimmermann has quit [Quit: Leaving]
rgallaispou has joined #wayland
thx_ has joined #wayland
thx has quit [Read error: Connection reset by peer]
thx_ has quit [Read error: Connection reset by peer]
anarsoul|2 has quit [Remote host closed the connection]
anarsoul has joined #wayland
leon-p has quit [Quit: leon-p]
rgallaispou has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
fmuellner has quit [Ping timeout: 480 seconds]
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
rgallaispou has joined #wayland
Elon_Satoshi1 has quit [Ping timeout: 480 seconds]
Elon_Satoshi1 has joined #wayland
___nick___ has quit [Ping timeout: 480 seconds]
yrlf has joined #wayland
<yrlf>
Hi! I'm currently looking at the linux-dmabuf-unstable-v1 protocol and I'm not quite sure how to interpret the "Y_INVERT" flag in the flags enum
<yrlf>
for output transforms in wl_output there is also a "flipped" property, which says "flipped around a vertical axis", aka it flips left and right
<yrlf>
initially I assumed Y_INVERT means literally inverting the y coordinate (i.e. y = -y if you coordinate space is -1 to 1), so flipping up and down
<yrlf>
but now that I've seen that output transforms use a different notion of flipping I'm no longer quite sure
<yrlf>
are those two concepts unrelated, and my initial interpretation of Y_INVERT is correct, or should they behave the same?
<emersion>
i don't think these flags are really used
<emersion>
daniels maybe knows? ^
<yrlf>
yeah, I haven't seen it used either, which is good
<yrlf>
if they were used I could just intuit what they should mean from what compositors actually put into the buffer
<daniels>
indeed
<emersion>
daniels, would it be fine to fail the import if any flag is set?
<daniels>
it does mean the same thing, which is that the first pixel in memory is (0,y) and the last is (x,0)
<daniels>
the reason it's there is because clients and buffer producers may want to be mutually unaware of transforms
<yrlf>
oh so Y_INVERT means "flips left and right"?
hardening_ has quit [Remote host closed the connection]
<daniels>
er, no? literally just flips on its axis, so it still progresses left to right with increasing memory address, but progresses bottom to top
<daniels>
anyway, imagine you have a GPU which can only render in GL co-ord space (increasing memory -> decreasing Y co-ord), and you have a client which wants to render 90° rotated
<yrlf>
oh okay, then I misunderstood what that flag means
<daniels>
in that case, the client wants to set the 90°-rotated surface transform, but the GL driver needs to be able to inform the compositor that the buffer is also upside-down
<daniels>
the two need separate requests for that
<daniels>
this is a completely theoretical case - I'm not aware of any real-world platform which hits this
<daniels>
so to answer emersion's question, yeah, it's completely fine to just fail if that flag is set :)
<yrlf>
do you by any chance know how to inform the GL driver that a dmabuf is Y_INVERT when importing a dmabuf into an EGLImage?
rgallaispou1 has joined #wayland
<daniels>
there are no EGL flags for that, you just have to flip texture coords yourself
<yrlf>
ahh
<daniels>
or just reject all such buffers :)
rgallaispou has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
Elon_Satoshi1 has quit [Ping timeout: 480 seconds]
rgallaispou has joined #wayland
rgallaispou1 has quit [Read error: Connection reset by peer]
novakane has quit [Quit: WeeChat 3.3]
rasterman has quit [Quit: Gettin' stinky!]
<any1>
nb. y_inverted can be composed with the output transform as WL_OUTPUT_TRANSFORM_FLIPPED_180. That way, whatever code you use to handle output transforms handles the y-flip for you
rgallaispou has quit [Read error: Connection reset by peer]
<any1>
In GL, that would be a transformation matrix which you apply to the texture when rendering it to your GL surface
<any1>
yrlf: At last, I feel like I should warn you that export-dmabuf does not work consistently between different platforms and applications. You may get tearing, artefacts, mixed frames or worse.
<any1>
Screencopy is the safe choice.
<daniels>
yeah, you definitely need to work in steps from buffer -> surface -> (view? -> ) output, and apply those transforms cumulatively
rgallaispou has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
spstarr has quit [Remote host closed the connection]