Collaboration on standard Wayland protocol extensions

[Ladislav Igrec]

hello, i have a proposal for this
first time using a mailing list so i hope i do it right-ish


protocol for screenshots:

client -> server: "can i get a screenshot ?"
server -> client: "sure, here it is" / "no"
server would send the screenshot via memfd or write() or something.
something like [type/format][length][data] (bit more futureproof then that, though)

for hotkeys:
client -> server: "can i get all alt+F5 events ?"
server -> client: "sure, i'l send them to you" / "no"

for streaming, i don't know how exactly does it work under wayland.
if a compositor can close the stream, then there is no problem

i suggest the transport layer to be UDS for 3 reasons
1. if the file is not in the predetermined place (example /run/wayland-ext/$COMPOSITOR_PID) then the compositor obviously doesn't support the extensions
(while at it, this doesn't have to be wayland exclusive)
2. the compositor can check the PID of the client
3. the compositor can send fds


rationales:
the list of supported features does not have to be gotten as the compositor saying "no" means "no", for whatever reason.
ofc the "what do you support" should be part of the protocol anyway
(the "no" can also be "NO_PRIVILEDGE" or "IDK_WHAT_YOU_ARE_TALKING_ABOUT")

it being UDS the compositor can get the PID, UID and GID of the client.
the compositor can then verify the client by looking at its /proc/$PID/exe.

this minimizes the whole priviledges thing in the protocol and lets the compositor writers choose how they will implement it.
examples:
a compositor that always does/allows what it can.
a compositor that asks the user then (optionally) remembers the answer
a compositor that asks some priviledges daemon "can this process do this?"

i would suggest that the compositor makes a list in human readable format in a file that only the "wayland_compositor" GID can read or write to.
something like:
$EXE_FROM_PROC $UID $GID PERMISSION1 PERMISSION2 etc..



Ladislav Igrec

"hope-ing he is making sense"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160331/bd8bca77/attachment.html>