detached 426e60c

feat(protocol): linux-dmabuf-v1 bindings

commit
426e60cab2e787d22a21545e6c6e19ff5f1a1174
author
brice · · 2026-09-25 05:34 UTC
parent
2513cf9
signature
GPG VerifiedCD88F9E564E0102646FB6077A1A07C7C7C3E349D · arch-gpg Verified for the committer email
3 files · +955 -0
Split
UnifiedSplit
M protocol/gen.go +1 -0
@@ -8,3 +8,4 @@ package protocol
88 //go:generate go run ../cmd/wlgen -package xdgdecoration -out xdgdecoration/xdgdecoration.go -import xdgshell=github.com/bnema/purego-libwayland/protocol/xdgshell -import-xml xdgshell=../protocols/xdg-shell.xml ../protocols/xdg-decoration-unstable-v1.xml
99 //go:generate go run ../cmd/wlgen -package viewporter -out viewporter/viewporter.go -import wayland=github.com/bnema/purego-libwayland/protocol/wayland -import-xml wayland=../protocols/wayland.xml ../protocols/viewporter.xml
1010 //go:generate go run ../cmd/wlgen -package fractionalscale -out fractionalscale/fractionalscale.go -import wayland=github.com/bnema/purego-libwayland/protocol/wayland -import-xml wayland=../protocols/wayland.xml ../protocols/fractional-scale-v1.xml
11+//go:generate go run ../cmd/wlgen -package linuxdmabuf -out linuxdmabuf/linuxdmabuf.go -import wayland=github.com/bnema/purego-libwayland/protocol/wayland -import-xml wayland=../protocols/wayland.xml ../protocols/linux-dmabuf-v1.xml
@@ -8,3 +8,4 @@ package protocol
8 //go:generate go run ../cmd/wlgen -package xdgdecoration -out xdgdecoration/xdgdecoration.go -import xdgshell=github.com/bnema/purego-libwayland/protocol/xdgshell -import-xml xdgshell=../protocols/xdg-shell.xml ../protocols/xdg-decoration-unstable-v1.xml8 //go:generate go run ../cmd/wlgen -package xdgdecoration -out xdgdecoration/xdgdecoration.go -import xdgshell=github.com/bnema/purego-libwayland/protocol/xdgshell -import-xml xdgshell=../protocols/xdg-shell.xml ../protocols/xdg-decoration-unstable-v1.xml
9 //go:generate go run ../cmd/wlgen -package viewporter -out viewporter/viewporter.go -import wayland=github.com/bnema/purego-libwayland/protocol/wayland -import-xml wayland=../protocols/wayland.xml ../protocols/viewporter.xml9 //go:generate go run ../cmd/wlgen -package viewporter -out viewporter/viewporter.go -import wayland=github.com/bnema/purego-libwayland/protocol/wayland -import-xml wayland=../protocols/wayland.xml ../protocols/viewporter.xml
10 //go:generate go run ../cmd/wlgen -package fractionalscale -out fractionalscale/fractionalscale.go -import wayland=github.com/bnema/purego-libwayland/protocol/wayland -import-xml wayland=../protocols/wayland.xml ../protocols/fractional-scale-v1.xml10 //go:generate go run ../cmd/wlgen -package fractionalscale -out fractionalscale/fractionalscale.go -import wayland=github.com/bnema/purego-libwayland/protocol/wayland -import-xml wayland=../protocols/wayland.xml ../protocols/fractional-scale-v1.xml
11+//go:generate go run ../cmd/wlgen -package linuxdmabuf -out linuxdmabuf/linuxdmabuf.go -import wayland=github.com/bnema/purego-libwayland/protocol/wayland -import-xml wayland=../protocols/wayland.xml ../protocols/linux-dmabuf-v1.xml
A protocol/linuxdmabuf/linuxdmabuf.go +331 -0
@@ -0,0 +1,331 @@
1+// Code generated by wlgen; DO NOT EDIT.
2+package linuxdmabuf
3+
4+import (
5+ "fmt"
6+ wayland "github.com/bnema/purego-libwayland/protocol/wayland"
7+ "github.com/bnema/purego-libwayland/server"
8+ "runtime"
9+)
10+
11+var ZwpLinuxDmabufV1Interface *server.Interface
12+var ZwpLinuxBufferParamsV1Interface *server.Interface
13+var ZwpLinuxDmabufFeedbackV1Interface *server.Interface
14+
15+func init() {
16+ ZwpLinuxDmabufV1Interface = &server.Interface{Name: "zwp_linux_dmabuf_v1", Version: 6}
17+ ZwpLinuxBufferParamsV1Interface = &server.Interface{Name: "zwp_linux_buffer_params_v1", Version: 6}
18+ ZwpLinuxDmabufFeedbackV1Interface = &server.Interface{Name: "zwp_linux_dmabuf_feedback_v1", Version: 6}
19+ ZwpLinuxDmabufV1Interface.Requests = []server.Message{
20+ {Name: "destroy", Signature: "", Types: []*server.Interface{}},
21+ {Name: "create_params", Signature: "n", Types: []*server.Interface{ZwpLinuxBufferParamsV1Interface}},
22+ {Name: "get_default_feedback", Signature: "4n", Types: []*server.Interface{ZwpLinuxDmabufFeedbackV1Interface}},
23+ {Name: "get_surface_feedback", Signature: "4no", Types: []*server.Interface{ZwpLinuxDmabufFeedbackV1Interface, wayland.SurfaceInterface}},
24+ }
25+ ZwpLinuxDmabufV1Interface.Events = []server.Message{
26+ {Name: "format", Signature: "u", Types: []*server.Interface{nil}},
27+ {Name: "modifier", Signature: "3uuu", Types: []*server.Interface{nil, nil, nil}},
28+ }
29+ ZwpLinuxBufferParamsV1Interface.Requests = []server.Message{
30+ {Name: "destroy", Signature: "", Types: []*server.Interface{}},
31+ {Name: "add", Signature: "huuuuu", Types: []*server.Interface{nil, nil, nil, nil, nil, nil}},
32+ {Name: "create", Signature: "iiuu", Types: []*server.Interface{nil, nil, nil, nil}},
33+ {Name: "create_immed", Signature: "2niiuu", Types: []*server.Interface{wayland.BufferInterface, nil, nil, nil, nil}},
34+ {Name: "set_sampling_device", Signature: "6a", Types: []*server.Interface{nil}},
35+ }
36+ ZwpLinuxBufferParamsV1Interface.Events = []server.Message{
37+ {Name: "created", Signature: "n", Types: []*server.Interface{wayland.BufferInterface}},
38+ {Name: "failed", Signature: "", Types: []*server.Interface{}},
39+ }
40+ ZwpLinuxDmabufFeedbackV1Interface.Requests = []server.Message{
41+ {Name: "destroy", Signature: "", Types: []*server.Interface{}},
42+ }
43+ ZwpLinuxDmabufFeedbackV1Interface.Events = []server.Message{
44+ {Name: "done", Signature: "", Types: []*server.Interface{}},
45+ {Name: "format_table", Signature: "hu", Types: []*server.Interface{nil, nil}},
46+ {Name: "main_device", Signature: "a", Types: []*server.Interface{nil}},
47+ {Name: "tranche_done", Signature: "", Types: []*server.Interface{}},
48+ {Name: "tranche_target_device", Signature: "a", Types: []*server.Interface{nil}},
49+ {Name: "tranche_formats", Signature: "a", Types: []*server.Interface{nil}},
50+ {Name: "tranche_flags", Signature: "u", Types: []*server.Interface{nil}},
51+ }
52+ if err := server.NewInterfaces(ZwpLinuxDmabufV1Interface, ZwpLinuxBufferParamsV1Interface, ZwpLinuxDmabufFeedbackV1Interface); err != nil {
53+ panic(err)
54+ }
55+}
56+
57+// ZwpLinuxDmabufV1 factory for creating dmabuf-based wl_buffers.
58+type ZwpLinuxDmabufV1 struct{ *server.Resource }
59+
60+func WrapZwpLinuxDmabufV1(r *server.Resource) *ZwpLinuxDmabufV1 {
61+ if r == nil {
62+ return nil
63+ }
64+ return &ZwpLinuxDmabufV1{r}
65+}
66+
67+const ZwpLinuxDmabufV1RequestDestroy uint32 = 0
68+const ZwpLinuxDmabufV1RequestCreateParams uint32 = 1
69+const ZwpLinuxDmabufV1RequestGetDefaultFeedback uint32 = 2
70+const ZwpLinuxDmabufV1RequestGetSurfaceFeedback uint32 = 3
71+const ZwpLinuxDmabufV1EventFormat uint32 = 0
72+const ZwpLinuxDmabufV1EventModifier uint32 = 1
73+
74+// ZwpLinuxDmabufV1Handler handles zwp_linux_dmabuf_v1 requests.
75+type ZwpLinuxDmabufV1Handler interface {
76+ Destroy(self *ZwpLinuxDmabufV1)
77+ CreateParams(self *ZwpLinuxDmabufV1, paramsId uint32)
78+ GetDefaultFeedback(self *ZwpLinuxDmabufV1, id uint32)
79+ GetSurfaceFeedback(self *ZwpLinuxDmabufV1, id uint32, surface *wayland.Surface)
80+}
81+
82+func NewZwpLinuxDmabufV1(c server.Client, version int32, id uint32, h ZwpLinuxDmabufV1Handler) (*ZwpLinuxDmabufV1, error) {
83+ if h == nil {
84+ return nil, fmt.Errorf("purego-libwayland: nil handler for zwp_linux_dmabuf_v1")
85+ }
86+ var self *ZwpLinuxDmabufV1
87+ r, err := c.CreateResource(ZwpLinuxDmabufV1Interface, version, id, func(_ *server.Resource, opcode uint32, args []server.Arg) {
88+ switch opcode {
89+ case 0:
90+ h.Destroy(self)
91+ self.Destroy()
92+ case 1:
93+ h.CreateParams(self, args[0].NewID())
94+ case 2:
95+ h.GetDefaultFeedback(self, args[0].NewID())
96+ case 3:
97+ h.GetSurfaceFeedback(self, args[0].NewID(), wayland.WrapSurface(args[1].Resource()))
98+ }
99+ })
100+ if err != nil {
101+ return nil, err
102+ }
103+ self = WrapZwpLinuxDmabufV1(r)
104+ r.Data = self
105+ return self, nil
106+}
107+
108+// SendFormat supported buffer format.
109+func (self *ZwpLinuxDmabufV1) SendFormat(format uint32) {
110+ self.PostEvent(ZwpLinuxDmabufV1EventFormat, server.Uint(format))
111+}
112+
113+// SendModifier supported buffer format modifier (since version 3).
114+func (self *ZwpLinuxDmabufV1) SendModifier(format uint32, modifierHi uint32, modifierLo uint32) {
115+ self.PostEvent(ZwpLinuxDmabufV1EventModifier, server.Uint(format), server.Uint(modifierHi), server.Uint(modifierLo))
116+}
117+func NewZwpLinuxDmabufV1Global(d *server.Display, version int32, bind server.BindFunc) error {
118+ return d.CreateGlobal(ZwpLinuxDmabufV1Interface, version, bind)
119+}
120+
121+// ZwpLinuxBufferParamsV1 parameters for creating a dmabuf-based wl_buffer.
122+type ZwpLinuxBufferParamsV1 struct{ *server.Resource }
123+
124+func WrapZwpLinuxBufferParamsV1(r *server.Resource) *ZwpLinuxBufferParamsV1 {
125+ if r == nil {
126+ return nil
127+ }
128+ return &ZwpLinuxBufferParamsV1{r}
129+}
130+
131+const ZwpLinuxBufferParamsV1RequestDestroy uint32 = 0
132+const ZwpLinuxBufferParamsV1RequestAdd uint32 = 1
133+const ZwpLinuxBufferParamsV1RequestCreate uint32 = 2
134+const ZwpLinuxBufferParamsV1RequestCreateImmed uint32 = 3
135+const ZwpLinuxBufferParamsV1RequestSetSamplingDevice uint32 = 4
136+const ZwpLinuxBufferParamsV1EventCreated uint32 = 0
137+const ZwpLinuxBufferParamsV1EventFailed uint32 = 1
138+
139+// ZwpLinuxBufferParamsV1Error .
140+type ZwpLinuxBufferParamsV1Error uint32
141+
142+const (
143+ ZwpLinuxBufferParamsV1ErrorAlreadyUsed ZwpLinuxBufferParamsV1Error = 0
144+ ZwpLinuxBufferParamsV1ErrorPlaneIdx ZwpLinuxBufferParamsV1Error = 1
145+ ZwpLinuxBufferParamsV1ErrorPlaneSet ZwpLinuxBufferParamsV1Error = 2
146+ ZwpLinuxBufferParamsV1ErrorIncomplete ZwpLinuxBufferParamsV1Error = 3
147+ ZwpLinuxBufferParamsV1ErrorInvalidFormat ZwpLinuxBufferParamsV1Error = 4
148+ ZwpLinuxBufferParamsV1ErrorInvalidDimensions ZwpLinuxBufferParamsV1Error = 5
149+ ZwpLinuxBufferParamsV1ErrorOutOfBounds ZwpLinuxBufferParamsV1Error = 6
150+ ZwpLinuxBufferParamsV1ErrorInvalidWlBuffer ZwpLinuxBufferParamsV1Error = 7
151+ ZwpLinuxBufferParamsV1ErrorInvalidDevTSize ZwpLinuxBufferParamsV1Error = 8
152+)
153+
154+// ZwpLinuxBufferParamsV1Flags (bitfield).
155+type ZwpLinuxBufferParamsV1Flags uint32
156+
157+const (
158+ ZwpLinuxBufferParamsV1FlagsYInvert ZwpLinuxBufferParamsV1Flags = 1
159+ ZwpLinuxBufferParamsV1FlagsInterlaced ZwpLinuxBufferParamsV1Flags = 2
160+ ZwpLinuxBufferParamsV1FlagsBottomFirst ZwpLinuxBufferParamsV1Flags = 4
161+)
162+
163+// ZwpLinuxBufferParamsV1Handler handles zwp_linux_buffer_params_v1 requests.
164+type ZwpLinuxBufferParamsV1Handler interface {
165+ Destroy(self *ZwpLinuxBufferParamsV1)
166+ Add(self *ZwpLinuxBufferParamsV1, fd int, planeIdx uint32, offset uint32, stride uint32, modifierHi uint32, modifierLo uint32)
167+ Create(self *ZwpLinuxBufferParamsV1, width int32, height int32, format uint32, flags uint32)
168+ CreateImmed(self *ZwpLinuxBufferParamsV1, bufferId uint32, width int32, height int32, format uint32, flags uint32)
169+ SetSamplingDevice(self *ZwpLinuxBufferParamsV1, device []byte)
170+}
171+
172+func NewZwpLinuxBufferParamsV1(c server.Client, version int32, id uint32, h ZwpLinuxBufferParamsV1Handler) (*ZwpLinuxBufferParamsV1, error) {
173+ if h == nil {
174+ return nil, fmt.Errorf("purego-libwayland: nil handler for zwp_linux_buffer_params_v1")
175+ }
176+ var self *ZwpLinuxBufferParamsV1
177+ r, err := c.CreateResource(ZwpLinuxBufferParamsV1Interface, version, id, func(_ *server.Resource, opcode uint32, args []server.Arg) {
178+ switch opcode {
179+ case 0:
180+ h.Destroy(self)
181+ self.Destroy()
182+ case 1:
183+ h.Add(self, args[0].Fd(), args[1].Uint(), args[2].Uint(), args[3].Uint(), args[4].Uint(), args[5].Uint())
184+ case 2:
185+ h.Create(self, args[0].Int(), args[1].Int(), args[2].Uint(), args[3].Uint())
186+ case 3:
187+ h.CreateImmed(self, args[0].NewID(), args[1].Int(), args[2].Int(), args[3].Uint(), args[4].Uint())
188+ case 4:
189+ h.SetSamplingDevice(self, args[0].Array())
190+ }
191+ })
192+ if err != nil {
193+ return nil, err
194+ }
195+ self = WrapZwpLinuxBufferParamsV1(r)
196+ r.Data = self
197+ return self, nil
198+}
199+
200+// SendCreated buffer creation succeeded.
201+func (self *ZwpLinuxBufferParamsV1) SendCreated(buffer *wayland.Buffer) {
202+ self.PostEvent(ZwpLinuxBufferParamsV1EventCreated, server.NewID(resourceOf(buffer)))
203+}
204+
205+// SendFailed buffer creation failed.
206+func (self *ZwpLinuxBufferParamsV1) SendFailed() {
207+ self.PostEvent(ZwpLinuxBufferParamsV1EventFailed)
208+}
209+func NewZwpLinuxBufferParamsV1Global(d *server.Display, version int32, bind server.BindFunc) error {
210+ return d.CreateGlobal(ZwpLinuxBufferParamsV1Interface, version, bind)
211+}
212+
213+// ZwpLinuxDmabufFeedbackV1 dmabuf feedback.
214+type ZwpLinuxDmabufFeedbackV1 struct{ *server.Resource }
215+
216+func WrapZwpLinuxDmabufFeedbackV1(r *server.Resource) *ZwpLinuxDmabufFeedbackV1 {
217+ if r == nil {
218+ return nil
219+ }
220+ return &ZwpLinuxDmabufFeedbackV1{r}
221+}
222+
223+const ZwpLinuxDmabufFeedbackV1RequestDestroy uint32 = 0
224+const ZwpLinuxDmabufFeedbackV1EventDone uint32 = 0
225+const ZwpLinuxDmabufFeedbackV1EventFormatTable uint32 = 1
226+const ZwpLinuxDmabufFeedbackV1EventMainDevice uint32 = 2
227+const ZwpLinuxDmabufFeedbackV1EventTrancheDone uint32 = 3
228+const ZwpLinuxDmabufFeedbackV1EventTrancheTargetDevice uint32 = 4
229+const ZwpLinuxDmabufFeedbackV1EventTrancheFormats uint32 = 5
230+const ZwpLinuxDmabufFeedbackV1EventTrancheFlags uint32 = 6
231+
232+// ZwpLinuxDmabufFeedbackV1TrancheFlags (bitfield).
233+type ZwpLinuxDmabufFeedbackV1TrancheFlags uint32
234+
235+const (
236+ ZwpLinuxDmabufFeedbackV1TrancheFlagsScanout ZwpLinuxDmabufFeedbackV1TrancheFlags = 1
237+ ZwpLinuxDmabufFeedbackV1TrancheFlagsSampling ZwpLinuxDmabufFeedbackV1TrancheFlags = 2
238+)
239+
240+// ZwpLinuxDmabufFeedbackV1Handler handles zwp_linux_dmabuf_feedback_v1 requests.
241+type ZwpLinuxDmabufFeedbackV1Handler interface {
242+ Destroy(self *ZwpLinuxDmabufFeedbackV1)
243+}
244+
245+func NewZwpLinuxDmabufFeedbackV1(c server.Client, version int32, id uint32, h ZwpLinuxDmabufFeedbackV1Handler) (*ZwpLinuxDmabufFeedbackV1, error) {
246+ if h == nil {
247+ return nil, fmt.Errorf("purego-libwayland: nil handler for zwp_linux_dmabuf_feedback_v1")
248+ }
249+ var self *ZwpLinuxDmabufFeedbackV1
250+ r, err := c.CreateResource(ZwpLinuxDmabufFeedbackV1Interface, version, id, func(_ *server.Resource, opcode uint32, args []server.Arg) {
251+ switch opcode {
252+ case 0:
253+ h.Destroy(self)
254+ self.Destroy()
255+ }
256+ })
257+ if err != nil {
258+ return nil, err
259+ }
260+ self = WrapZwpLinuxDmabufFeedbackV1(r)
261+ r.Data = self
262+ return self, nil
263+}
264+
265+// SendDone all feedback has been sent.
266+func (self *ZwpLinuxDmabufFeedbackV1) SendDone() {
267+ self.PostEvent(ZwpLinuxDmabufFeedbackV1EventDone)
268+}
269+
270+// SendFormatTable format and modifier table.
271+func (self *ZwpLinuxDmabufFeedbackV1) SendFormatTable(fd int, size uint32) {
272+ self.PostEvent(ZwpLinuxDmabufFeedbackV1EventFormatTable, server.Fd(fd), server.Uint(size))
273+}
274+
275+// SendMainDevice preferred main device.
276+func (self *ZwpLinuxDmabufFeedbackV1) SendMainDevice(device []byte) {
277+ var p runtime.Pinner
278+ defer p.Unpin()
279+ self.PostEvent(ZwpLinuxDmabufFeedbackV1EventMainDevice, server.Array(&p, device))
280+}
281+
282+// SendTrancheDone a preference tranche has been sent.
283+func (self *ZwpLinuxDmabufFeedbackV1) SendTrancheDone() {
284+ self.PostEvent(ZwpLinuxDmabufFeedbackV1EventTrancheDone)
285+}
286+
287+// SendTrancheTargetDevice target device.
288+func (self *ZwpLinuxDmabufFeedbackV1) SendTrancheTargetDevice(device []byte) {
289+ var p runtime.Pinner
290+ defer p.Unpin()
291+ self.PostEvent(ZwpLinuxDmabufFeedbackV1EventTrancheTargetDevice, server.Array(&p, device))
292+}
293+
294+// SendTrancheFormats supported buffer format modifiers.
295+func (self *ZwpLinuxDmabufFeedbackV1) SendTrancheFormats(indices []byte) {
296+ var p runtime.Pinner
297+ defer p.Unpin()
298+ self.PostEvent(ZwpLinuxDmabufFeedbackV1EventTrancheFormats, server.Array(&p, indices))
299+}
300+
301+// SendTrancheFlags tranche flags.
302+func (self *ZwpLinuxDmabufFeedbackV1) SendTrancheFlags(flags uint32) {
303+ self.PostEvent(ZwpLinuxDmabufFeedbackV1EventTrancheFlags, server.Uint(flags))
304+}
305+func NewZwpLinuxDmabufFeedbackV1Global(d *server.Display, version int32, bind server.BindFunc) error {
306+ return d.CreateGlobal(ZwpLinuxDmabufFeedbackV1Interface, version, bind)
307+}
308+func resourceOf(v interface{ GetResource() *server.Resource }) *server.Resource {
309+ if v == nil {
310+ return nil
311+ }
312+ return v.GetResource()
313+}
314+func (self *ZwpLinuxDmabufV1) GetResource() *server.Resource {
315+ if self == nil {
316+ return nil
317+ }
318+ return self.Resource
319+}
320+func (self *ZwpLinuxBufferParamsV1) GetResource() *server.Resource {
321+ if self == nil {
322+ return nil
323+ }
324+ return self.Resource
325+}
326+func (self *ZwpLinuxDmabufFeedbackV1) GetResource() *server.Resource {
327+ if self == nil {
328+ return nil
329+ }
330+ return self.Resource
331+}
@@ -0,0 +1,331 @@
1+// Code generated by wlgen; DO NOT EDIT.
2+package linuxdmabuf
3+
4+import (
5+ "fmt"
6+ wayland "github.com/bnema/purego-libwayland/protocol/wayland"
7+ "github.com/bnema/purego-libwayland/server"
8+ "runtime"
9+)
10+
11+var ZwpLinuxDmabufV1Interface *server.Interface
12+var ZwpLinuxBufferParamsV1Interface *server.Interface
13+var ZwpLinuxDmabufFeedbackV1Interface *server.Interface
14+
15+func init() {
16+ ZwpLinuxDmabufV1Interface = &server.Interface{Name: "zwp_linux_dmabuf_v1", Version: 6}
17+ ZwpLinuxBufferParamsV1Interface = &server.Interface{Name: "zwp_linux_buffer_params_v1", Version: 6}
18+ ZwpLinuxDmabufFeedbackV1Interface = &server.Interface{Name: "zwp_linux_dmabuf_feedback_v1", Version: 6}
19+ ZwpLinuxDmabufV1Interface.Requests = []server.Message{
20+ {Name: "destroy", Signature: "", Types: []*server.Interface{}},
21+ {Name: "create_params", Signature: "n", Types: []*server.Interface{ZwpLinuxBufferParamsV1Interface}},
22+ {Name: "get_default_feedback", Signature: "4n", Types: []*server.Interface{ZwpLinuxDmabufFeedbackV1Interface}},
23+ {Name: "get_surface_feedback", Signature: "4no", Types: []*server.Interface{ZwpLinuxDmabufFeedbackV1Interface, wayland.SurfaceInterface}},
24+ }
25+ ZwpLinuxDmabufV1Interface.Events = []server.Message{
26+ {Name: "format", Signature: "u", Types: []*server.Interface{nil}},
27+ {Name: "modifier", Signature: "3uuu", Types: []*server.Interface{nil, nil, nil}},
28+ }
29+ ZwpLinuxBufferParamsV1Interface.Requests = []server.Message{
30+ {Name: "destroy", Signature: "", Types: []*server.Interface{}},
31+ {Name: "add", Signature: "huuuuu", Types: []*server.Interface{nil, nil, nil, nil, nil, nil}},
32+ {Name: "create", Signature: "iiuu", Types: []*server.Interface{nil, nil, nil, nil}},
33+ {Name: "create_immed", Signature: "2niiuu", Types: []*server.Interface{wayland.BufferInterface, nil, nil, nil, nil}},
34+ {Name: "set_sampling_device", Signature: "6a", Types: []*server.Interface{nil}},
35+ }
36+ ZwpLinuxBufferParamsV1Interface.Events = []server.Message{
37+ {Name: "created", Signature: "n", Types: []*server.Interface{wayland.BufferInterface}},
38+ {Name: "failed", Signature: "", Types: []*server.Interface{}},
39+ }
40+ ZwpLinuxDmabufFeedbackV1Interface.Requests = []server.Message{
41+ {Name: "destroy", Signature: "", Types: []*server.Interface{}},
42+ }
43+ ZwpLinuxDmabufFeedbackV1Interface.Events = []server.Message{
44+ {Name: "done", Signature: "", Types: []*server.Interface{}},
45+ {Name: "format_table", Signature: "hu", Types: []*server.Interface{nil, nil}},
46+ {Name: "main_device", Signature: "a", Types: []*server.Interface{nil}},
47+ {Name: "tranche_done", Signature: "", Types: []*server.Interface{}},
48+ {Name: "tranche_target_device", Signature: "a", Types: []*server.Interface{nil}},
49+ {Name: "tranche_formats", Signature: "a", Types: []*server.Interface{nil}},
50+ {Name: "tranche_flags", Signature: "u", Types: []*server.Interface{nil}},
51+ }
52+ if err := server.NewInterfaces(ZwpLinuxDmabufV1Interface, ZwpLinuxBufferParamsV1Interface, ZwpLinuxDmabufFeedbackV1Interface); err != nil {
53+ panic(err)
54+ }
55+}
56+
57+// ZwpLinuxDmabufV1 factory for creating dmabuf-based wl_buffers.
58+type ZwpLinuxDmabufV1 struct{ *server.Resource }
59+
60+func WrapZwpLinuxDmabufV1(r *server.Resource) *ZwpLinuxDmabufV1 {
61+ if r == nil {
62+ return nil
63+ }
64+ return &ZwpLinuxDmabufV1{r}
65+}
66+
67+const ZwpLinuxDmabufV1RequestDestroy uint32 = 0
68+const ZwpLinuxDmabufV1RequestCreateParams uint32 = 1
69+const ZwpLinuxDmabufV1RequestGetDefaultFeedback uint32 = 2
70+const ZwpLinuxDmabufV1RequestGetSurfaceFeedback uint32 = 3
71+const ZwpLinuxDmabufV1EventFormat uint32 = 0
72+const ZwpLinuxDmabufV1EventModifier uint32 = 1
73+
74+// ZwpLinuxDmabufV1Handler handles zwp_linux_dmabuf_v1 requests.
75+type ZwpLinuxDmabufV1Handler interface {
76+ Destroy(self *ZwpLinuxDmabufV1)
77+ CreateParams(self *ZwpLinuxDmabufV1, paramsId uint32)
78+ GetDefaultFeedback(self *ZwpLinuxDmabufV1, id uint32)
79+ GetSurfaceFeedback(self *ZwpLinuxDmabufV1, id uint32, surface *wayland.Surface)
80+}
81+
82+func NewZwpLinuxDmabufV1(c server.Client, version int32, id uint32, h ZwpLinuxDmabufV1Handler) (*ZwpLinuxDmabufV1, error) {
83+ if h == nil {
84+ return nil, fmt.Errorf("purego-libwayland: nil handler for zwp_linux_dmabuf_v1")
85+ }
86+ var self *ZwpLinuxDmabufV1
87+ r, err := c.CreateResource(ZwpLinuxDmabufV1Interface, version, id, func(_ *server.Resource, opcode uint32, args []server.Arg) {
88+ switch opcode {
89+ case 0:
90+ h.Destroy(self)
91+ self.Destroy()
92+ case 1:
93+ h.CreateParams(self, args[0].NewID())
94+ case 2:
95+ h.GetDefaultFeedback(self, args[0].NewID())
96+ case 3:
97+ h.GetSurfaceFeedback(self, args[0].NewID(), wayland.WrapSurface(args[1].Resource()))
98+ }
99+ })
100+ if err != nil {
101+ return nil, err
102+ }
103+ self = WrapZwpLinuxDmabufV1(r)
104+ r.Data = self
105+ return self, nil
106+}
107+
108+// SendFormat supported buffer format.
109+func (self *ZwpLinuxDmabufV1) SendFormat(format uint32) {
110+ self.PostEvent(ZwpLinuxDmabufV1EventFormat, server.Uint(format))
111+}
112+
113+// SendModifier supported buffer format modifier (since version 3).
114+func (self *ZwpLinuxDmabufV1) SendModifier(format uint32, modifierHi uint32, modifierLo uint32) {
115+ self.PostEvent(ZwpLinuxDmabufV1EventModifier, server.Uint(format), server.Uint(modifierHi), server.Uint(modifierLo))
116+}
117+func NewZwpLinuxDmabufV1Global(d *server.Display, version int32, bind server.BindFunc) error {
118+ return d.CreateGlobal(ZwpLinuxDmabufV1Interface, version, bind)
119+}
120+
121+// ZwpLinuxBufferParamsV1 parameters for creating a dmabuf-based wl_buffer.
122+type ZwpLinuxBufferParamsV1 struct{ *server.Resource }
123+
124+func WrapZwpLinuxBufferParamsV1(r *server.Resource) *ZwpLinuxBufferParamsV1 {
125+ if r == nil {
126+ return nil
127+ }
128+ return &ZwpLinuxBufferParamsV1{r}
129+}
130+
131+const ZwpLinuxBufferParamsV1RequestDestroy uint32 = 0
132+const ZwpLinuxBufferParamsV1RequestAdd uint32 = 1
133+const ZwpLinuxBufferParamsV1RequestCreate uint32 = 2
134+const ZwpLinuxBufferParamsV1RequestCreateImmed uint32 = 3
135+const ZwpLinuxBufferParamsV1RequestSetSamplingDevice uint32 = 4
136+const ZwpLinuxBufferParamsV1EventCreated uint32 = 0
137+const ZwpLinuxBufferParamsV1EventFailed uint32 = 1
138+
139+// ZwpLinuxBufferParamsV1Error .
140+type ZwpLinuxBufferParamsV1Error uint32
141+
142+const (
143+ ZwpLinuxBufferParamsV1ErrorAlreadyUsed ZwpLinuxBufferParamsV1Error = 0
144+ ZwpLinuxBufferParamsV1ErrorPlaneIdx ZwpLinuxBufferParamsV1Error = 1
145+ ZwpLinuxBufferParamsV1ErrorPlaneSet ZwpLinuxBufferParamsV1Error = 2
146+ ZwpLinuxBufferParamsV1ErrorIncomplete ZwpLinuxBufferParamsV1Error = 3
147+ ZwpLinuxBufferParamsV1ErrorInvalidFormat ZwpLinuxBufferParamsV1Error = 4
148+ ZwpLinuxBufferParamsV1ErrorInvalidDimensions ZwpLinuxBufferParamsV1Error = 5
149+ ZwpLinuxBufferParamsV1ErrorOutOfBounds ZwpLinuxBufferParamsV1Error = 6
150+ ZwpLinuxBufferParamsV1ErrorInvalidWlBuffer ZwpLinuxBufferParamsV1Error = 7
151+ ZwpLinuxBufferParamsV1ErrorInvalidDevTSize ZwpLinuxBufferParamsV1Error = 8
152+)
153+
154+// ZwpLinuxBufferParamsV1Flags (bitfield).
155+type ZwpLinuxBufferParamsV1Flags uint32
156+
157+const (
158+ ZwpLinuxBufferParamsV1FlagsYInvert ZwpLinuxBufferParamsV1Flags = 1
159+ ZwpLinuxBufferParamsV1FlagsInterlaced ZwpLinuxBufferParamsV1Flags = 2
160+ ZwpLinuxBufferParamsV1FlagsBottomFirst ZwpLinuxBufferParamsV1Flags = 4
161+)
162+
163+// ZwpLinuxBufferParamsV1Handler handles zwp_linux_buffer_params_v1 requests.
164+type ZwpLinuxBufferParamsV1Handler interface {
165+ Destroy(self *ZwpLinuxBufferParamsV1)
166+ Add(self *ZwpLinuxBufferParamsV1, fd int, planeIdx uint32, offset uint32, stride uint32, modifierHi uint32, modifierLo uint32)
167+ Create(self *ZwpLinuxBufferParamsV1, width int32, height int32, format uint32, flags uint32)
168+ CreateImmed(self *ZwpLinuxBufferParamsV1, bufferId uint32, width int32, height int32, format uint32, flags uint32)
169+ SetSamplingDevice(self *ZwpLinuxBufferParamsV1, device []byte)
170+}
171+
172+func NewZwpLinuxBufferParamsV1(c server.Client, version int32, id uint32, h ZwpLinuxBufferParamsV1Handler) (*ZwpLinuxBufferParamsV1, error) {
173+ if h == nil {
174+ return nil, fmt.Errorf("purego-libwayland: nil handler for zwp_linux_buffer_params_v1")
175+ }
176+ var self *ZwpLinuxBufferParamsV1
177+ r, err := c.CreateResource(ZwpLinuxBufferParamsV1Interface, version, id, func(_ *server.Resource, opcode uint32, args []server.Arg) {
178+ switch opcode {
179+ case 0:
180+ h.Destroy(self)
181+ self.Destroy()
182+ case 1:
183+ h.Add(self, args[0].Fd(), args[1].Uint(), args[2].Uint(), args[3].Uint(), args[4].Uint(), args[5].Uint())
184+ case 2:
185+ h.Create(self, args[0].Int(), args[1].Int(), args[2].Uint(), args[3].Uint())
186+ case 3:
187+ h.CreateImmed(self, args[0].NewID(), args[1].Int(), args[2].Int(), args[3].Uint(), args[4].Uint())
188+ case 4:
189+ h.SetSamplingDevice(self, args[0].Array())
190+ }
191+ })
192+ if err != nil {
193+ return nil, err
194+ }
195+ self = WrapZwpLinuxBufferParamsV1(r)
196+ r.Data = self
197+ return self, nil
198+}
199+
200+// SendCreated buffer creation succeeded.
201+func (self *ZwpLinuxBufferParamsV1) SendCreated(buffer *wayland.Buffer) {
202+ self.PostEvent(ZwpLinuxBufferParamsV1EventCreated, server.NewID(resourceOf(buffer)))
203+}
204+
205+// SendFailed buffer creation failed.
206+func (self *ZwpLinuxBufferParamsV1) SendFailed() {
207+ self.PostEvent(ZwpLinuxBufferParamsV1EventFailed)
208+}
209+func NewZwpLinuxBufferParamsV1Global(d *server.Display, version int32, bind server.BindFunc) error {
210+ return d.CreateGlobal(ZwpLinuxBufferParamsV1Interface, version, bind)
211+}
212+
213+// ZwpLinuxDmabufFeedbackV1 dmabuf feedback.
214+type ZwpLinuxDmabufFeedbackV1 struct{ *server.Resource }
215+
216+func WrapZwpLinuxDmabufFeedbackV1(r *server.Resource) *ZwpLinuxDmabufFeedbackV1 {
217+ if r == nil {
218+ return nil
219+ }
220+ return &ZwpLinuxDmabufFeedbackV1{r}
221+}
222+
223+const ZwpLinuxDmabufFeedbackV1RequestDestroy uint32 = 0
224+const ZwpLinuxDmabufFeedbackV1EventDone uint32 = 0
225+const ZwpLinuxDmabufFeedbackV1EventFormatTable uint32 = 1
226+const ZwpLinuxDmabufFeedbackV1EventMainDevice uint32 = 2
227+const ZwpLinuxDmabufFeedbackV1EventTrancheDone uint32 = 3
228+const ZwpLinuxDmabufFeedbackV1EventTrancheTargetDevice uint32 = 4
229+const ZwpLinuxDmabufFeedbackV1EventTrancheFormats uint32 = 5
230+const ZwpLinuxDmabufFeedbackV1EventTrancheFlags uint32 = 6
231+
232+// ZwpLinuxDmabufFeedbackV1TrancheFlags (bitfield).
233+type ZwpLinuxDmabufFeedbackV1TrancheFlags uint32
234+
235+const (
236+ ZwpLinuxDmabufFeedbackV1TrancheFlagsScanout ZwpLinuxDmabufFeedbackV1TrancheFlags = 1
237+ ZwpLinuxDmabufFeedbackV1TrancheFlagsSampling ZwpLinuxDmabufFeedbackV1TrancheFlags = 2
238+)
239+
240+// ZwpLinuxDmabufFeedbackV1Handler handles zwp_linux_dmabuf_feedback_v1 requests.
241+type ZwpLinuxDmabufFeedbackV1Handler interface {
242+ Destroy(self *ZwpLinuxDmabufFeedbackV1)
243+}
244+
245+func NewZwpLinuxDmabufFeedbackV1(c server.Client, version int32, id uint32, h ZwpLinuxDmabufFeedbackV1Handler) (*ZwpLinuxDmabufFeedbackV1, error) {
246+ if h == nil {
247+ return nil, fmt.Errorf("purego-libwayland: nil handler for zwp_linux_dmabuf_feedback_v1")
248+ }
249+ var self *ZwpLinuxDmabufFeedbackV1
250+ r, err := c.CreateResource(ZwpLinuxDmabufFeedbackV1Interface, version, id, func(_ *server.Resource, opcode uint32, args []server.Arg) {
251+ switch opcode {
252+ case 0:
253+ h.Destroy(self)
254+ self.Destroy()
255+ }
256+ })
257+ if err != nil {
258+ return nil, err
259+ }
260+ self = WrapZwpLinuxDmabufFeedbackV1(r)
261+ r.Data = self
262+ return self, nil
263+}
264+
265+// SendDone all feedback has been sent.
266+func (self *ZwpLinuxDmabufFeedbackV1) SendDone() {
267+ self.PostEvent(ZwpLinuxDmabufFeedbackV1EventDone)
268+}
269+
270+// SendFormatTable format and modifier table.
271+func (self *ZwpLinuxDmabufFeedbackV1) SendFormatTable(fd int, size uint32) {
272+ self.PostEvent(ZwpLinuxDmabufFeedbackV1EventFormatTable, server.Fd(fd), server.Uint(size))
273+}
274+
275+// SendMainDevice preferred main device.
276+func (self *ZwpLinuxDmabufFeedbackV1) SendMainDevice(device []byte) {
277+ var p runtime.Pinner
278+ defer p.Unpin()
279+ self.PostEvent(ZwpLinuxDmabufFeedbackV1EventMainDevice, server.Array(&p, device))
280+}
281+
282+// SendTrancheDone a preference tranche has been sent.
283+func (self *ZwpLinuxDmabufFeedbackV1) SendTrancheDone() {
284+ self.PostEvent(ZwpLinuxDmabufFeedbackV1EventTrancheDone)
285+}
286+
287+// SendTrancheTargetDevice target device.
288+func (self *ZwpLinuxDmabufFeedbackV1) SendTrancheTargetDevice(device []byte) {
289+ var p runtime.Pinner
290+ defer p.Unpin()
291+ self.PostEvent(ZwpLinuxDmabufFeedbackV1EventTrancheTargetDevice, server.Array(&p, device))
292+}
293+
294+// SendTrancheFormats supported buffer format modifiers.
295+func (self *ZwpLinuxDmabufFeedbackV1) SendTrancheFormats(indices []byte) {
296+ var p runtime.Pinner
297+ defer p.Unpin()
298+ self.PostEvent(ZwpLinuxDmabufFeedbackV1EventTrancheFormats, server.Array(&p, indices))
299+}
300+
301+// SendTrancheFlags tranche flags.
302+func (self *ZwpLinuxDmabufFeedbackV1) SendTrancheFlags(flags uint32) {
303+ self.PostEvent(ZwpLinuxDmabufFeedbackV1EventTrancheFlags, server.Uint(flags))
304+}
305+func NewZwpLinuxDmabufFeedbackV1Global(d *server.Display, version int32, bind server.BindFunc) error {
306+ return d.CreateGlobal(ZwpLinuxDmabufFeedbackV1Interface, version, bind)
307+}
308+func resourceOf(v interface{ GetResource() *server.Resource }) *server.Resource {
309+ if v == nil {
310+ return nil
311+ }
312+ return v.GetResource()
313+}
314+func (self *ZwpLinuxDmabufV1) GetResource() *server.Resource {
315+ if self == nil {
316+ return nil
317+ }
318+ return self.Resource
319+}
320+func (self *ZwpLinuxBufferParamsV1) GetResource() *server.Resource {
321+ if self == nil {
322+ return nil
323+ }
324+ return self.Resource
325+}
326+func (self *ZwpLinuxDmabufFeedbackV1) GetResource() *server.Resource {
327+ if self == nil {
328+ return nil
329+ }
330+ return self.Resource
331+}
A protocols/linux-dmabuf-v1.xml +623 -0
@@ -0,0 +1,623 @@
1+<?xml version="1.0" encoding="UTF-8"?>
2+<protocol name="linux_dmabuf_v1">
3+
4+ <copyright>
5+ Copyright © 2014, 2015 Collabora, Ltd.
6+
7+ Permission is hereby granted, free of charge, to any person obtaining a
8+ copy of this software and associated documentation files (the "Software"),
9+ to deal in the Software without restriction, including without limitation
10+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
11+ and/or sell copies of the Software, and to permit persons to whom the
12+ Software is furnished to do so, subject to the following conditions:
13+
14+ The above copyright notice and this permission notice (including the next
15+ paragraph) shall be included in all copies or substantial portions of the
16+ Software.
17+
18+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
19+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
20+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
21+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
22+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
23+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
24+ DEALINGS IN THE SOFTWARE.
25+ </copyright>
26+
27+ <interface name="zwp_linux_dmabuf_v1" version="6">
28+ <description summary="factory for creating dmabuf-based wl_buffers">
29+ This interface offers ways to create generic dmabuf-based wl_buffers.
30+
31+ For more information about dmabuf, see:
32+ https://www.kernel.org/doc/html/next/userspace-api/dma-buf-alloc-exchange.html
33+
34+ Clients can use the get_surface_feedback request to get dmabuf feedback
35+ for a particular surface. If the client wants to retrieve feedback not
36+ tied to a surface, they can use the get_default_feedback request.
37+
38+ The following are required from clients:
39+
40+ - Clients must ensure that either all data in the dma-buf is
41+ coherent for all subsequent read access or that coherency is
42+ correctly handled by the underlying kernel-side dma-buf
43+ implementation.
44+
45+ - Don't make any more attachments after sending the buffer to the
46+ compositor. Making more attachments later increases the risk of
47+ the compositor not being able to use (re-import) an existing
48+ dmabuf-based wl_buffer.
49+
50+ The underlying graphics stack must ensure the following:
51+
52+ - The dmabuf file descriptors relayed to the server will stay valid
53+ for the whole lifetime of the wl_buffer. This means the server may
54+ at any time use those fds to import the dmabuf into any kernel
55+ sub-system that might accept it.
56+
57+ However, when the underlying graphics stack fails to deliver the
58+ promise, because of e.g. a device hot-unplug which raises internal
59+ errors, after the wl_buffer has been successfully created the
60+ compositor must not raise protocol errors to the client when dmabuf
61+ import later fails.
62+
63+ To create a wl_buffer from one or more dmabufs, a client creates a
64+ zwp_linux_buffer_params_v1 object with a zwp_linux_dmabuf_v1.create_params
65+ request. All planes required by the intended format are added with
66+ the 'add' request. Finally, a 'create' or 'create_immed' request is
67+ issued, which has the following outcome depending on the import success.
68+
69+ The 'create' request,
70+ - on success, triggers a 'created' event which provides the final
71+ wl_buffer to the client.
72+ - on failure, triggers a 'failed' event to convey that the server
73+ cannot use the dmabufs received from the client.
74+
75+ For the 'create_immed' request,
76+ - on success, the server immediately imports the added dmabufs to
77+ create a wl_buffer. No event is sent from the server in this case.
78+ - on failure, the server can choose to either:
79+ - terminate the client by raising a fatal error.
80+ - mark the wl_buffer as failed, and send a 'failed' event to the
81+ client. If the client uses a failed wl_buffer as an argument to any
82+ request, the behaviour is compositor implementation-defined.
83+
84+ For all DRM formats and unless specified in another protocol extension,
85+ pre-multiplied alpha is used for pixel values.
86+
87+ Unless specified otherwise in another protocol extension, implicit
88+ synchronization is used. In other words, compositors and clients must
89+ wait and signal fences implicitly passed via the DMA-BUF's reservation
90+ mechanism.
91+ </description>
92+
93+ <request name="destroy" type="destructor">
94+ <description summary="unbind the factory">
95+ Objects created through this interface, especially wl_buffers, will
96+ remain valid.
97+ </description>
98+ </request>
99+
100+ <request name="create_params">
101+ <description summary="create a temporary object for buffer parameters">
102+ This temporary object is used to collect multiple dmabuf handles into
103+ a single batch to create a wl_buffer. It can only be used once and
104+ should be destroyed after a 'created' or 'failed' event has been
105+ received.
106+ </description>
107+ <arg name="params_id" type="new_id" interface="zwp_linux_buffer_params_v1"
108+ summary="id for the newly created zwp_linux_buffer_params_v1"/>
109+ </request>
110+
111+ <event name="format" deprecated-since="4">
112+ <description summary="supported buffer format">
113+ This event advertises one buffer format that the server supports.
114+ All the supported formats are advertised once when the client
115+ binds to this interface. A roundtrip after binding guarantees
116+ that the client has received all supported formats.
117+
118+ For the definition of the format codes, see the
119+ zwp_linux_buffer_params_v1::create request.
120+
121+ Starting version 4, the format event is deprecated and must not be
122+ sent by compositors. Instead, use get_default_feedback or
123+ get_surface_feedback.
124+ </description>
125+ <arg name="format" type="uint" summary="DRM_FORMAT code"/>
126+ </event>
127+
128+ <event name="modifier" since="3" deprecated-since="4">
129+ <description summary="supported buffer format modifier">
130+ This event advertises the formats that the server supports, along with
131+ the modifiers supported for each format. All the supported modifiers
132+ for all the supported formats are advertised once when the client
133+ binds to this interface. A roundtrip after binding guarantees that
134+ the client has received all supported format-modifier pairs.
135+
136+ For legacy support, DRM_FORMAT_MOD_INVALID (that is, modifier_hi ==
137+ 0x00ffffff and modifier_lo == 0xffffffff) is allowed in this event.
138+ It indicates that the server can support the format with an implicit
139+ modifier. When a plane has DRM_FORMAT_MOD_INVALID as its modifier, it
140+ is as if no explicit modifier is specified. The effective modifier
141+ will be derived from the dmabuf.
142+
143+ A compositor that sends valid modifiers and DRM_FORMAT_MOD_INVALID for
144+ a given format supports both explicit modifiers and implicit modifiers.
145+
146+ For the definition of the format and modifier codes, see the
147+ zwp_linux_buffer_params_v1::create and zwp_linux_buffer_params_v1::add
148+ requests.
149+
150+ Starting version 4, the modifier event is deprecated and must not be
151+ sent by compositors. Instead, use get_default_feedback or
152+ get_surface_feedback.
153+ </description>
154+ <arg name="format" type="uint" summary="DRM_FORMAT code"/>
155+ <arg name="modifier_hi" type="uint"
156+ summary="high 32 bits of layout modifier"/>
157+ <arg name="modifier_lo" type="uint"
158+ summary="low 32 bits of layout modifier"/>
159+ </event>
160+
161+ <!-- Version 4 additions -->
162+
163+ <request name="get_default_feedback" since="4">
164+ <description summary="get default feedback">
165+ This request creates a new zwp_linux_dmabuf_feedback_v1 object not bound
166+ to a particular surface. This object will deliver feedback about dmabuf
167+ parameters to use if the client doesn't support per-surface feedback
168+ (see get_surface_feedback).
169+ </description>
170+ <arg name="id" type="new_id" interface="zwp_linux_dmabuf_feedback_v1"/>
171+ </request>
172+
173+ <request name="get_surface_feedback" since="4">
174+ <description summary="get feedback for a surface">
175+ This request creates a new zwp_linux_dmabuf_feedback_v1 object for the
176+ specified wl_surface. This object will deliver feedback about dmabuf
177+ parameters to use for buffers attached to this surface.
178+
179+ If the surface is destroyed before the zwp_linux_dmabuf_feedback_v1 object,
180+ the feedback object becomes inert.
181+ </description>
182+ <arg name="id" type="new_id" interface="zwp_linux_dmabuf_feedback_v1"/>
183+ <arg name="surface" type="object" interface="wl_surface"/>
184+ </request>
185+ </interface>
186+
187+ <interface name="zwp_linux_buffer_params_v1" version="6">
188+ <description summary="parameters for creating a dmabuf-based wl_buffer">
189+ This temporary object is a collection of dmabufs and other
190+ parameters that together form a single logical buffer. The temporary
191+ object may eventually create one wl_buffer unless cancelled by
192+ destroying it before requesting 'create'.
193+
194+ Single-planar formats only require one dmabuf, however
195+ multi-planar formats may require more than one dmabuf. For all
196+ formats, an 'add' request must be called once per plane (even if the
197+ underlying dmabuf fd is identical).
198+
199+ You must use consecutive plane indices ('plane_idx' argument for 'add')
200+ from zero to the number of planes used by the drm_fourcc format code.
201+ All planes required by the format must be given exactly once, but can
202+ be given in any order. Each plane index can only be set once; subsequent
203+ calls with a plane index which has already been set will result in a
204+ plane_set error being generated.
205+ </description>
206+
207+ <enum name="error">
208+ <entry name="already_used" value="0"
209+ summary="the zwp_linux_buffer_params_v1 object has already been used to create a wl_buffer"/>
210+ <entry name="plane_idx" value="1"
211+ summary="plane index out of bounds"/>
212+ <entry name="plane_set" value="2"
213+ summary="the plane index was already set"/>
214+ <entry name="incomplete" value="3"
215+ summary="missing or too many planes to create a buffer"/>
216+ <entry name="invalid_format" value="4"
217+ summary="format not supported"/>
218+ <entry name="invalid_dimensions" value="5"
219+ summary="invalid width or height"/>
220+ <entry name="out_of_bounds" value="6"
221+ summary="offset + stride * height goes out of dmabuf bounds"/>
222+ <entry name="invalid_wl_buffer" value="7"
223+ summary="invalid wl_buffer resulted from importing dmabufs via
224+ the create_immed request on given buffer_params"/>
225+ <entry name="invalid_dev_t_size" value="8"
226+ summary="an array with mismatching size for a dev_t was used"/>
227+ </enum>
228+
229+ <request name="destroy" type="destructor">
230+ <description summary="delete this object, used or not">
231+ Cleans up the temporary data sent to the server for dmabuf-based
232+ wl_buffer creation.
233+ </description>
234+ </request>
235+
236+ <request name="add">
237+ <description summary="add a dmabuf to the temporary set">
238+ This request adds one dmabuf to the set in this
239+ zwp_linux_buffer_params_v1.
240+
241+ The 64-bit unsigned value combined from modifier_hi and modifier_lo
242+ is the dmabuf layout modifier. DRM AddFB2 ioctl calls this the
243+ fb modifier, which is defined in drm_mode.h of Linux UAPI.
244+ This is an opaque token. Drivers use this token to express tiling,
245+ compression, etc. driver-specific modifications to the base format
246+ defined by the DRM fourcc code.
247+
248+ Starting from version 4, the invalid_format protocol error is sent if
249+ the format + modifier pair was not advertised as supported.
250+
251+ Starting from version 5, the invalid_format protocol error is sent if
252+ all planes don't use the same modifier.
253+
254+ This request raises the PLANE_IDX error if plane_idx is too large.
255+ The error PLANE_SET is raised if attempting to set a plane that
256+ was already set.
257+ </description>
258+ <arg name="fd" type="fd" summary="dmabuf fd"/>
259+ <arg name="plane_idx" type="uint" summary="plane index"/>
260+ <arg name="offset" type="uint" summary="offset in bytes"/>
261+ <arg name="stride" type="uint" summary="stride in bytes"/>
262+ <arg name="modifier_hi" type="uint"
263+ summary="high 32 bits of layout modifier"/>
264+ <arg name="modifier_lo" type="uint"
265+ summary="low 32 bits of layout modifier"/>
266+ </request>
267+
268+ <enum name="flags" bitfield="true">
269+ <entry name="y_invert" value="1" summary="contents are y-inverted"/>
270+ <entry name="interlaced" value="2" summary="content is interlaced"/>
271+ <entry name="bottom_first" value="4" summary="bottom field first"/>
272+ </enum>
273+
274+ <request name="create">
275+ <description summary="create a wl_buffer from the given dmabufs">
276+ This asks for creation of a wl_buffer from the added dmabuf
277+ buffers. The wl_buffer is not created immediately but returned via
278+ the 'created' event if the dmabuf sharing succeeds. The sharing
279+ may fail at runtime for reasons a client cannot predict, in
280+ which case the 'failed' event is triggered.
281+
282+ The 'format' argument is a DRM_FORMAT code, as defined by the
283+ libdrm's drm_fourcc.h. The Linux kernel's DRM sub-system is the
284+ authoritative source on how the format codes should work.
285+
286+ The 'flags' is a bitfield of the flags defined in enum "flags".
287+ 'y_invert' means that the image needs to be y-flipped.
288+
289+ Flag 'interlaced' means that the frame in the buffer is not
290+ progressive as usual, but interlaced. An interlaced buffer as
291+ supported here must always contain both top and bottom fields.
292+ The top field always begins on the first pixel row. The temporal
293+ ordering between the two fields is top field first, unless
294+ 'bottom_first' is specified. It is undefined whether 'bottom_first'
295+ is ignored if 'interlaced' is not set.
296+
297+ This protocol does not convey any information about field rate,
298+ duration, or timing, other than the relative ordering between the
299+ two fields in one buffer. A compositor may have to estimate the
300+ intended field rate from the incoming buffer rate. It is undefined
301+ whether the time of receiving wl_surface.commit with a new buffer
302+ attached, applying the wl_surface state, wl_surface.frame callback
303+ trigger, presentation, or any other point in the compositor cycle
304+ is used to measure the frame or field times. There is no support
305+ for detecting missed or late frames/fields/buffers either, and
306+ there is no support whatsoever for cooperating with interlaced
307+ compositor output.
308+
309+ The composited image quality resulting from the use of interlaced
310+ buffers is explicitly undefined. A compositor may use elaborate
311+ hardware features or software to deinterlace and create progressive
312+ output frames from a sequence of interlaced input buffers, or it
313+ may produce substandard image quality. However, compositors that
314+ cannot guarantee reasonable image quality in all cases are recommended
315+ to just reject all interlaced buffers.
316+
317+ Any argument errors, including non-positive width or height,
318+ mismatch between the number of planes and the format, bad
319+ format, bad offset or stride, may be indicated by fatal protocol
320+ errors: INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS,
321+ OUT_OF_BOUNDS.
322+
323+ Dmabuf import errors in the server that are not obvious client
324+ bugs are returned via the 'failed' event as non-fatal. This
325+ allows attempting dmabuf sharing and falling back in the client
326+ if it fails.
327+
328+ This request can be sent only once in the object's lifetime, after
329+ which the only legal request is destroy. This object should be
330+ destroyed after issuing a 'create' request. Attempting to use this
331+ object after issuing 'create' raises the ALREADY_USED protocol error.
332+
333+ It is not mandatory to issue 'create'. If a client wants to
334+ cancel the buffer creation, it can just destroy this object.
335+ </description>
336+ <arg name="width" type="int" summary="base plane width in pixels"/>
337+ <arg name="height" type="int" summary="base plane height in pixels"/>
338+ <arg name="format" type="uint" summary="DRM_FORMAT code"/>
339+ <arg name="flags" type="uint" enum="flags" summary="see enum flags"/>
340+ </request>
341+
342+ <event name="created">
343+ <description summary="buffer creation succeeded">
344+ This event indicates that the attempted buffer creation was
345+ successful. It provides the new wl_buffer referencing the dmabuf(s).
346+
347+ Upon receiving this event, the client should destroy the
348+ zwp_linux_buffer_params_v1 object.
349+ </description>
350+ <arg name="buffer" type="new_id" interface="wl_buffer"
351+ summary="id for the the newly created wl_buffer"/>
352+ </event>
353+
354+ <event name="failed">
355+ <description summary="buffer creation failed">
356+ This event indicates that the attempted buffer creation has
357+ failed. It usually means that one of the dmabuf constraints
358+ has not been fulfilled.
359+
360+ Upon receiving this event, the client should destroy the
361+ zwp_linux_buffer_params_v1 object.
362+ </description>
363+ </event>
364+
365+ <request name="create_immed" since="2">
366+ <description summary="immediately create a wl_buffer from the given
367+ dmabufs">
368+ This asks for immediate creation of a wl_buffer by importing the
369+ added dmabufs.
370+
371+ In case of import success, no event is sent from the server, and the
372+ wl_buffer is ready to be used by the client.
373+
374+ Upon import failure, either of the following may happen, as seen fit
375+ by the implementation:
376+ - the client is terminated with one of the following fatal protocol
377+ errors:
378+ - INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS, OUT_OF_BOUNDS,
379+ in case of argument errors such as mismatch between the number
380+ of planes and the format, bad format, non-positive width or
381+ height, or bad offset or stride.
382+ - INVALID_WL_BUFFER, in case the cause for failure is unknown or
383+ platform specific.
384+ - the server creates an invalid wl_buffer, marks it as failed and
385+ sends a 'failed' event to the client. The result of using this
386+ invalid wl_buffer as an argument in any request by the client is
387+ defined by the compositor implementation.
388+
389+ This takes the same arguments as a 'create' request, and obeys the
390+ same restrictions.
391+ </description>
392+ <arg name="buffer_id" type="new_id" interface="wl_buffer"
393+ summary="id for the newly created wl_buffer"/>
394+ <arg name="width" type="int" summary="base plane width in pixels"/>
395+ <arg name="height" type="int" summary="base plane height in pixels"/>
396+ <arg name="format" type="uint" summary="DRM_FORMAT code"/>
397+ <arg name="flags" type="uint" enum="flags" summary="see enum flags"/>
398+ </request>
399+
400+ <request name="set_sampling_device" since="6">
401+ <description summary="set the target device of the wl_buffer">
402+ Set the device the compositor should import the dmabufs to for sampling
403+ in the next create or create_immed request.
404+
405+ To avoid race conditions when the compositor removes a device from the
406+ tranches, it is not a protocol error if the device hasn't been advertised
407+ by the compositor in a tranche with the sampling flag, but the import is
408+ likely to fail in that case.
409+
410+ If the client doesn't know a suitable target device, it shouldn't set one,
411+ and the compositor should attempt import on all devices it supports.
412+
413+ If the array is too small to contain a dev_t or larger than required, the
414+ invalid_dev_t_size error will be emitted.
415+ </description>
416+ <arg name="device" type="array" summary="device dev_t value"/>
417+ </request>
418+ </interface>
419+
420+ <interface name="zwp_linux_dmabuf_feedback_v1" version="6">
421+ <description summary="dmabuf feedback">
422+ This object advertises dmabuf parameters feedback. This includes the
423+ preferred devices and the supported formats/modifiers.
424+
425+ The parameters are sent once when this object is created and whenever they
426+ change. The done event is always sent once after all parameters have been
427+ sent. When a single parameter changes, all parameters are re-sent by the
428+ compositor.
429+
430+ Compositors can re-send the parameters when the current client buffer
431+ allocations are sub-optimal. Compositors should not re-send the
432+ parameters if re-allocating the buffers would not result in a more optimal
433+ configuration. In particular, compositors should avoid sending the exact
434+ same parameters multiple times in a row.
435+
436+ The tranche_target_device and tranche_formats events are grouped by
437+ tranches of preference. For each tranche, a tranche_target_device, one
438+ tranche_flags and one or more tranche_formats events are sent, followed
439+ by a tranche_done event finishing the list. The tranches are sent in
440+ descending order of preference. All formats and modifiers in the same
441+ tranche have the same preference.
442+
443+ To send parameters, the compositor sends one main_device event (unless
444+ the client bound version 6 or above), tranches (each consisting of one
445+ tranche_target_device event, one tranche_flags event, tranche_formats
446+ events and then a tranche_done event), then one done event.
447+
448+ With version 6 and above, the compositor must always advertise at least
449+ one tranche with the sampling flag set.
450+ </description>
451+
452+ <request name="destroy" type="destructor">
453+ <description summary="destroy the feedback object">
454+ Using this request a client can tell the server that it is not going to
455+ use the zwp_linux_dmabuf_feedback_v1 object anymore.
456+ </description>
457+ </request>
458+
459+ <event name="done">
460+ <description summary="all feedback has been sent">
461+ This event is sent after all parameters of a zwp_linux_dmabuf_feedback_v1
462+ object have been sent.
463+
464+ This allows changes to the zwp_linux_dmabuf_feedback_v1 parameters to be
465+ seen as atomic, even if they happen via multiple events.
466+ </description>
467+ </event>
468+
469+ <event name="format_table">
470+ <description summary="format and modifier table">
471+ This event provides a file descriptor which can be memory-mapped to
472+ access the format and modifier table.
473+
474+ The table contains a tightly packed array of consecutive format +
475+ modifier pairs. Each pair is 16 bytes wide. It contains a format as a
476+ 32-bit unsigned integer, followed by 4 bytes of unused padding, and a
477+ modifier as a 64-bit unsigned integer. The native endianness is used.
478+
479+ The client must map the file descriptor in read-only private mode.
480+
481+ Compositors are not allowed to mutate the table file contents once this
482+ event has been sent. Instead, compositors must create a new, separate
483+ table file and re-send feedback parameters. Compositors are allowed to
484+ store duplicate format + modifier pairs in the table.
485+ </description>
486+ <arg name="fd" type="fd" summary="table file descriptor"/>
487+ <arg name="size" type="uint" summary="table size, in bytes"/>
488+ </event>
489+
490+ <event name="main_device" deprecated-since="6">
491+ <description summary="preferred main device">
492+ This event advertises the main device that the server prefers to use
493+ when direct scan-out to the target device isn't possible. The
494+ advertised main device may be different for each
495+ zwp_linux_dmabuf_feedback_v1 object, and may change over time.
496+
497+ There is exactly one main device. The compositor must send at least
498+ one preference tranche with tranche_target_device equal to main_device.
499+
500+ Clients need to create buffers that the main device can import and
501+ read from, otherwise creating the dmabuf wl_buffer will fail (see the
502+ zwp_linux_buffer_params_v1.create and create_immed requests for details).
503+ The main device will also likely be kept active by the compositor,
504+ so clients can use it instead of waking up another device for power
505+ savings.
506+
507+ In general the device is a DRM node. The DRM node type (primary vs.
508+ render) is unspecified. Clients must not rely on the compositor sending
509+ a particular node type. Clients cannot check two devices for equality
510+ by comparing the dev_t value.
511+
512+ If explicit modifiers are not supported and the client performs buffer
513+ allocations on a different device than the main device, then the client
514+ must force the buffer to have a linear layout.
515+
516+ With version 6 and above, this event is no longer sent. Clients should
517+ use a device with the sampling flag in the tranches instead.
518+ </description>
519+ <arg name="device" type="array" summary="device dev_t value"/>
520+ </event>
521+
522+ <event name="tranche_done">
523+ <description summary="a preference tranche has been sent">
524+ This event splits tranche_target_device and tranche_formats events into
525+ preference tranches. It is sent after a set of tranche_target_device
526+ and tranche_formats events; it represents the end of a tranche. The
527+ next tranche will have a lower preference.
528+ </description>
529+ </event>
530+
531+ <event name="tranche_target_device">
532+ <description summary="target device">
533+ This event advertises the target device that the server prefers to use
534+ for a buffer created given this tranche. The advertised target device
535+ may be different for each preference tranche, and may change over time.
536+
537+ There is exactly one target device per tranche.
538+
539+ The target device may be a scan-out device, for example if the
540+ compositor prefers to directly scan-out a buffer created given this
541+ tranche. The target device may be a rendering device, for example if
542+ the compositor prefers to texture from said buffer.
543+
544+ The client can use this hint to allocate the buffer in a way that makes
545+ it accessible from the target device, ideally directly. The buffer must
546+ still be accessible from a device with the sampling flag, either through
547+ direct import or a potentially more expensive fallback path. If the
548+ buffer can't be directly imported for sampling, then clients must be
549+ prepared for the compositor changing the tranche priority or making
550+ wl_buffer creation fail (see the zwp_linux_buffer_params_v1.create and
551+ create_immed requests for details).
552+
553+ If the device is a DRM node, the DRM node type (primary vs. render) is
554+ unspecified. Clients must not rely on the compositor sending a
555+ particular node type. Clients cannot check two devices for equality by
556+ comparing the dev_t value.
557+
558+ This event is tied to a preference tranche, see the tranche_done event.
559+ </description>
560+ <arg name="device" type="array" summary="device dev_t value"/>
561+ </event>
562+
563+ <event name="tranche_formats">
564+ <description summary="supported buffer format modifiers">
565+ This event advertises the format + modifier combinations that the
566+ compositor supports.
567+
568+ It carries an array of indices, each referring to a format + modifier
569+ pair in the last received format table (see the format_table event).
570+ Each index is a 16-bit unsigned integer in native endianness.
571+
572+ For legacy support, DRM_FORMAT_MOD_INVALID is an allowed modifier.
573+ It indicates that the server can support the format with an implicit
574+ modifier. When a buffer has DRM_FORMAT_MOD_INVALID as its modifier, it
575+ is as if no explicit modifier is specified. The effective modifier
576+ will be derived from the dmabuf.
577+
578+ A compositor that sends valid modifiers and DRM_FORMAT_MOD_INVALID for
579+ a given format supports both explicit modifiers and implicit modifiers.
580+
581+ Compositors must not send duplicate format + modifier pairs within the
582+ same tranche or across two different tranches with the same target
583+ device and flags.
584+
585+ This event is tied to a preference tranche, see the tranche_done event.
586+
587+ For the definition of the format and modifier codes, see the
588+ zwp_linux_buffer_params_v1.create request.
589+ </description>
590+ <arg name="indices" type="array" summary="array of 16-bit indexes"/>
591+ </event>
592+
593+ <enum name="tranche_flags" bitfield="true">
594+ <entry name="scanout" value="1" since="4">
595+ <description summary="direct scan-out tranche">
596+ The scanout flag is a hint that direct scan-out may be attempted by
597+ the compositor on the target device if the client appropriately
598+ allocates a buffer. How to allocate a buffer that can be scanned out
599+ on the target device is implementation-defined.
600+ </description>
601+ </entry>
602+ <entry name="sampling" value="2" since="6">
603+ <description summary="sampling tranche">
604+ The sampling flag describes that the compositor is able to efficiently
605+ sample from buffers imported to the target device if the client
606+ appropriately allocates a buffer. How to allocate a buffer that can be
607+ efficiently sampled on the target device is implementation defined.
608+ </description>
609+ </entry>
610+ </enum>
611+
612+ <event name="tranche_flags">
613+ <description summary="tranche flags">
614+ This event sets tranche-specific flags. This event is tied to a
615+ preference tranche, see the tranche_done event.
616+ With version 6 and above, the compositor must set at least one flag
617+ in each tranche.
618+ </description>
619+ <arg name="flags" type="uint" enum="tranche_flags" summary="tranche flags"/>
620+ </event>
621+ </interface>
622+
623+</protocol>
@@ -0,0 +1,623 @@
1+<?xml version="1.0" encoding="UTF-8"?>
2+<protocol name="linux_dmabuf_v1">
3+
4+ <copyright>
5+ Copyright © 2014, 2015 Collabora, Ltd.
6+
7+ Permission is hereby granted, free of charge, to any person obtaining a
8+ copy of this software and associated documentation files (the "Software"),
9+ to deal in the Software without restriction, including without limitation
10+ the rights to use, copy, modify, merge, publish, distribute, sublicense,
11+ and/or sell copies of the Software, and to permit persons to whom the
12+ Software is furnished to do so, subject to the following conditions:
13+
14+ The above copyright notice and this permission notice (including the next
15+ paragraph) shall be included in all copies or substantial portions of the
16+ Software.
17+
18+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
19+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
20+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
21+ THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
22+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
23+ FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
24+ DEALINGS IN THE SOFTWARE.
25+ </copyright>
26+
27+ <interface name="zwp_linux_dmabuf_v1" version="6">
28+ <description summary="factory for creating dmabuf-based wl_buffers">
29+ This interface offers ways to create generic dmabuf-based wl_buffers.
30+
31+ For more information about dmabuf, see:
32+ https://www.kernel.org/doc/html/next/userspace-api/dma-buf-alloc-exchange.html
33+
34+ Clients can use the get_surface_feedback request to get dmabuf feedback
35+ for a particular surface. If the client wants to retrieve feedback not
36+ tied to a surface, they can use the get_default_feedback request.
37+
38+ The following are required from clients:
39+
40+ - Clients must ensure that either all data in the dma-buf is
41+ coherent for all subsequent read access or that coherency is
42+ correctly handled by the underlying kernel-side dma-buf
43+ implementation.
44+
45+ - Don't make any more attachments after sending the buffer to the
46+ compositor. Making more attachments later increases the risk of
47+ the compositor not being able to use (re-import) an existing
48+ dmabuf-based wl_buffer.
49+
50+ The underlying graphics stack must ensure the following:
51+
52+ - The dmabuf file descriptors relayed to the server will stay valid
53+ for the whole lifetime of the wl_buffer. This means the server may
54+ at any time use those fds to import the dmabuf into any kernel
55+ sub-system that might accept it.
56+
57+ However, when the underlying graphics stack fails to deliver the
58+ promise, because of e.g. a device hot-unplug which raises internal
59+ errors, after the wl_buffer has been successfully created the
60+ compositor must not raise protocol errors to the client when dmabuf
61+ import later fails.
62+
63+ To create a wl_buffer from one or more dmabufs, a client creates a
64+ zwp_linux_buffer_params_v1 object with a zwp_linux_dmabuf_v1.create_params
65+ request. All planes required by the intended format are added with
66+ the 'add' request. Finally, a 'create' or 'create_immed' request is
67+ issued, which has the following outcome depending on the import success.
68+
69+ The 'create' request,
70+ - on success, triggers a 'created' event which provides the final
71+ wl_buffer to the client.
72+ - on failure, triggers a 'failed' event to convey that the server
73+ cannot use the dmabufs received from the client.
74+
75+ For the 'create_immed' request,
76+ - on success, the server immediately imports the added dmabufs to
77+ create a wl_buffer. No event is sent from the server in this case.
78+ - on failure, the server can choose to either:
79+ - terminate the client by raising a fatal error.
80+ - mark the wl_buffer as failed, and send a 'failed' event to the
81+ client. If the client uses a failed wl_buffer as an argument to any
82+ request, the behaviour is compositor implementation-defined.
83+
84+ For all DRM formats and unless specified in another protocol extension,
85+ pre-multiplied alpha is used for pixel values.
86+
87+ Unless specified otherwise in another protocol extension, implicit
88+ synchronization is used. In other words, compositors and clients must
89+ wait and signal fences implicitly passed via the DMA-BUF's reservation
90+ mechanism.
91+ </description>
92+
93+ <request name="destroy" type="destructor">
94+ <description summary="unbind the factory">
95+ Objects created through this interface, especially wl_buffers, will
96+ remain valid.
97+ </description>
98+ </request>
99+
100+ <request name="create_params">
101+ <description summary="create a temporary object for buffer parameters">
102+ This temporary object is used to collect multiple dmabuf handles into
103+ a single batch to create a wl_buffer. It can only be used once and
104+ should be destroyed after a 'created' or 'failed' event has been
105+ received.
106+ </description>
107+ <arg name="params_id" type="new_id" interface="zwp_linux_buffer_params_v1"
108+ summary="id for the newly created zwp_linux_buffer_params_v1"/>
109+ </request>
110+
111+ <event name="format" deprecated-since="4">
112+ <description summary="supported buffer format">
113+ This event advertises one buffer format that the server supports.
114+ All the supported formats are advertised once when the client
115+ binds to this interface. A roundtrip after binding guarantees
116+ that the client has received all supported formats.
117+
118+ For the definition of the format codes, see the
119+ zwp_linux_buffer_params_v1::create request.
120+
121+ Starting version 4, the format event is deprecated and must not be
122+ sent by compositors. Instead, use get_default_feedback or
123+ get_surface_feedback.
124+ </description>
125+ <arg name="format" type="uint" summary="DRM_FORMAT code"/>
126+ </event>
127+
128+ <event name="modifier" since="3" deprecated-since="4">
129+ <description summary="supported buffer format modifier">
130+ This event advertises the formats that the server supports, along with
131+ the modifiers supported for each format. All the supported modifiers
132+ for all the supported formats are advertised once when the client
133+ binds to this interface. A roundtrip after binding guarantees that
134+ the client has received all supported format-modifier pairs.
135+
136+ For legacy support, DRM_FORMAT_MOD_INVALID (that is, modifier_hi ==
137+ 0x00ffffff and modifier_lo == 0xffffffff) is allowed in this event.
138+ It indicates that the server can support the format with an implicit
139+ modifier. When a plane has DRM_FORMAT_MOD_INVALID as its modifier, it
140+ is as if no explicit modifier is specified. The effective modifier
141+ will be derived from the dmabuf.
142+
143+ A compositor that sends valid modifiers and DRM_FORMAT_MOD_INVALID for
144+ a given format supports both explicit modifiers and implicit modifiers.
145+
146+ For the definition of the format and modifier codes, see the
147+ zwp_linux_buffer_params_v1::create and zwp_linux_buffer_params_v1::add
148+ requests.
149+
150+ Starting version 4, the modifier event is deprecated and must not be
151+ sent by compositors. Instead, use get_default_feedback or
152+ get_surface_feedback.
153+ </description>
154+ <arg name="format" type="uint" summary="DRM_FORMAT code"/>
155+ <arg name="modifier_hi" type="uint"
156+ summary="high 32 bits of layout modifier"/>
157+ <arg name="modifier_lo" type="uint"
158+ summary="low 32 bits of layout modifier"/>
159+ </event>
160+
161+ <!-- Version 4 additions -->
162+
163+ <request name="get_default_feedback" since="4">
164+ <description summary="get default feedback">
165+ This request creates a new zwp_linux_dmabuf_feedback_v1 object not bound
166+ to a particular surface. This object will deliver feedback about dmabuf
167+ parameters to use if the client doesn't support per-surface feedback
168+ (see get_surface_feedback).
169+ </description>
170+ <arg name="id" type="new_id" interface="zwp_linux_dmabuf_feedback_v1"/>
171+ </request>
172+
173+ <request name="get_surface_feedback" since="4">
174+ <description summary="get feedback for a surface">
175+ This request creates a new zwp_linux_dmabuf_feedback_v1 object for the
176+ specified wl_surface. This object will deliver feedback about dmabuf
177+ parameters to use for buffers attached to this surface.
178+
179+ If the surface is destroyed before the zwp_linux_dmabuf_feedback_v1 object,
180+ the feedback object becomes inert.
181+ </description>
182+ <arg name="id" type="new_id" interface="zwp_linux_dmabuf_feedback_v1"/>
183+ <arg name="surface" type="object" interface="wl_surface"/>
184+ </request>
185+ </interface>
186+
187+ <interface name="zwp_linux_buffer_params_v1" version="6">
188+ <description summary="parameters for creating a dmabuf-based wl_buffer">
189+ This temporary object is a collection of dmabufs and other
190+ parameters that together form a single logical buffer. The temporary
191+ object may eventually create one wl_buffer unless cancelled by
192+ destroying it before requesting 'create'.
193+
194+ Single-planar formats only require one dmabuf, however
195+ multi-planar formats may require more than one dmabuf. For all
196+ formats, an 'add' request must be called once per plane (even if the
197+ underlying dmabuf fd is identical).
198+
199+ You must use consecutive plane indices ('plane_idx' argument for 'add')
200+ from zero to the number of planes used by the drm_fourcc format code.
201+ All planes required by the format must be given exactly once, but can
202+ be given in any order. Each plane index can only be set once; subsequent
203+ calls with a plane index which has already been set will result in a
204+ plane_set error being generated.
205+ </description>
206+
207+ <enum name="error">
208+ <entry name="already_used" value="0"
209+ summary="the zwp_linux_buffer_params_v1 object has already been used to create a wl_buffer"/>
210+ <entry name="plane_idx" value="1"
211+ summary="plane index out of bounds"/>
212+ <entry name="plane_set" value="2"
213+ summary="the plane index was already set"/>
214+ <entry name="incomplete" value="3"
215+ summary="missing or too many planes to create a buffer"/>
216+ <entry name="invalid_format" value="4"
217+ summary="format not supported"/>
218+ <entry name="invalid_dimensions" value="5"
219+ summary="invalid width or height"/>
220+ <entry name="out_of_bounds" value="6"
221+ summary="offset + stride * height goes out of dmabuf bounds"/>
222+ <entry name="invalid_wl_buffer" value="7"
223+ summary="invalid wl_buffer resulted from importing dmabufs via
224+ the create_immed request on given buffer_params"/>
225+ <entry name="invalid_dev_t_size" value="8"
226+ summary="an array with mismatching size for a dev_t was used"/>
227+ </enum>
228+
229+ <request name="destroy" type="destructor">
230+ <description summary="delete this object, used or not">
231+ Cleans up the temporary data sent to the server for dmabuf-based
232+ wl_buffer creation.
233+ </description>
234+ </request>
235+
236+ <request name="add">
237+ <description summary="add a dmabuf to the temporary set">
238+ This request adds one dmabuf to the set in this
239+ zwp_linux_buffer_params_v1.
240+
241+ The 64-bit unsigned value combined from modifier_hi and modifier_lo
242+ is the dmabuf layout modifier. DRM AddFB2 ioctl calls this the
243+ fb modifier, which is defined in drm_mode.h of Linux UAPI.
244+ This is an opaque token. Drivers use this token to express tiling,
245+ compression, etc. driver-specific modifications to the base format
246+ defined by the DRM fourcc code.
247+
248+ Starting from version 4, the invalid_format protocol error is sent if
249+ the format + modifier pair was not advertised as supported.
250+
251+ Starting from version 5, the invalid_format protocol error is sent if
252+ all planes don't use the same modifier.
253+
254+ This request raises the PLANE_IDX error if plane_idx is too large.
255+ The error PLANE_SET is raised if attempting to set a plane that
256+ was already set.
257+ </description>
258+ <arg name="fd" type="fd" summary="dmabuf fd"/>
259+ <arg name="plane_idx" type="uint" summary="plane index"/>
260+ <arg name="offset" type="uint" summary="offset in bytes"/>
261+ <arg name="stride" type="uint" summary="stride in bytes"/>
262+ <arg name="modifier_hi" type="uint"
263+ summary="high 32 bits of layout modifier"/>
264+ <arg name="modifier_lo" type="uint"
265+ summary="low 32 bits of layout modifier"/>
266+ </request>
267+
268+ <enum name="flags" bitfield="true">
269+ <entry name="y_invert" value="1" summary="contents are y-inverted"/>
270+ <entry name="interlaced" value="2" summary="content is interlaced"/>
271+ <entry name="bottom_first" value="4" summary="bottom field first"/>
272+ </enum>
273+
274+ <request name="create">
275+ <description summary="create a wl_buffer from the given dmabufs">
276+ This asks for creation of a wl_buffer from the added dmabuf
277+ buffers. The wl_buffer is not created immediately but returned via
278+ the 'created' event if the dmabuf sharing succeeds. The sharing
279+ may fail at runtime for reasons a client cannot predict, in
280+ which case the 'failed' event is triggered.
281+
282+ The 'format' argument is a DRM_FORMAT code, as defined by the
283+ libdrm's drm_fourcc.h. The Linux kernel's DRM sub-system is the
284+ authoritative source on how the format codes should work.
285+
286+ The 'flags' is a bitfield of the flags defined in enum "flags".
287+ 'y_invert' means that the image needs to be y-flipped.
288+
289+ Flag 'interlaced' means that the frame in the buffer is not
290+ progressive as usual, but interlaced. An interlaced buffer as
291+ supported here must always contain both top and bottom fields.
292+ The top field always begins on the first pixel row. The temporal
293+ ordering between the two fields is top field first, unless
294+ 'bottom_first' is specified. It is undefined whether 'bottom_first'
295+ is ignored if 'interlaced' is not set.
296+
297+ This protocol does not convey any information about field rate,
298+ duration, or timing, other than the relative ordering between the
299+ two fields in one buffer. A compositor may have to estimate the
300+ intended field rate from the incoming buffer rate. It is undefined
301+ whether the time of receiving wl_surface.commit with a new buffer
302+ attached, applying the wl_surface state, wl_surface.frame callback
303+ trigger, presentation, or any other point in the compositor cycle
304+ is used to measure the frame or field times. There is no support
305+ for detecting missed or late frames/fields/buffers either, and
306+ there is no support whatsoever for cooperating with interlaced
307+ compositor output.
308+
309+ The composited image quality resulting from the use of interlaced
310+ buffers is explicitly undefined. A compositor may use elaborate
311+ hardware features or software to deinterlace and create progressive
312+ output frames from a sequence of interlaced input buffers, or it
313+ may produce substandard image quality. However, compositors that
314+ cannot guarantee reasonable image quality in all cases are recommended
315+ to just reject all interlaced buffers.
316+
317+ Any argument errors, including non-positive width or height,
318+ mismatch between the number of planes and the format, bad
319+ format, bad offset or stride, may be indicated by fatal protocol
320+ errors: INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS,
321+ OUT_OF_BOUNDS.
322+
323+ Dmabuf import errors in the server that are not obvious client
324+ bugs are returned via the 'failed' event as non-fatal. This
325+ allows attempting dmabuf sharing and falling back in the client
326+ if it fails.
327+
328+ This request can be sent only once in the object's lifetime, after
329+ which the only legal request is destroy. This object should be
330+ destroyed after issuing a 'create' request. Attempting to use this
331+ object after issuing 'create' raises the ALREADY_USED protocol error.
332+
333+ It is not mandatory to issue 'create'. If a client wants to
334+ cancel the buffer creation, it can just destroy this object.
335+ </description>
336+ <arg name="width" type="int" summary="base plane width in pixels"/>
337+ <arg name="height" type="int" summary="base plane height in pixels"/>
338+ <arg name="format" type="uint" summary="DRM_FORMAT code"/>
339+ <arg name="flags" type="uint" enum="flags" summary="see enum flags"/>
340+ </request>
341+
342+ <event name="created">
343+ <description summary="buffer creation succeeded">
344+ This event indicates that the attempted buffer creation was
345+ successful. It provides the new wl_buffer referencing the dmabuf(s).
346+
347+ Upon receiving this event, the client should destroy the
348+ zwp_linux_buffer_params_v1 object.
349+ </description>
350+ <arg name="buffer" type="new_id" interface="wl_buffer"
351+ summary="id for the the newly created wl_buffer"/>
352+ </event>
353+
354+ <event name="failed">
355+ <description summary="buffer creation failed">
356+ This event indicates that the attempted buffer creation has
357+ failed. It usually means that one of the dmabuf constraints
358+ has not been fulfilled.
359+
360+ Upon receiving this event, the client should destroy the
361+ zwp_linux_buffer_params_v1 object.
362+ </description>
363+ </event>
364+
365+ <request name="create_immed" since="2">
366+ <description summary="immediately create a wl_buffer from the given
367+ dmabufs">
368+ This asks for immediate creation of a wl_buffer by importing the
369+ added dmabufs.
370+
371+ In case of import success, no event is sent from the server, and the
372+ wl_buffer is ready to be used by the client.
373+
374+ Upon import failure, either of the following may happen, as seen fit
375+ by the implementation:
376+ - the client is terminated with one of the following fatal protocol
377+ errors:
378+ - INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS, OUT_OF_BOUNDS,
379+ in case of argument errors such as mismatch between the number
380+ of planes and the format, bad format, non-positive width or
381+ height, or bad offset or stride.
382+ - INVALID_WL_BUFFER, in case the cause for failure is unknown or
383+ platform specific.
384+ - the server creates an invalid wl_buffer, marks it as failed and
385+ sends a 'failed' event to the client. The result of using this
386+ invalid wl_buffer as an argument in any request by the client is
387+ defined by the compositor implementation.
388+
389+ This takes the same arguments as a 'create' request, and obeys the
390+ same restrictions.
391+ </description>
392+ <arg name="buffer_id" type="new_id" interface="wl_buffer"
393+ summary="id for the newly created wl_buffer"/>
394+ <arg name="width" type="int" summary="base plane width in pixels"/>
395+ <arg name="height" type="int" summary="base plane height in pixels"/>
396+ <arg name="format" type="uint" summary="DRM_FORMAT code"/>
397+ <arg name="flags" type="uint" enum="flags" summary="see enum flags"/>
398+ </request>
399+
400+ <request name="set_sampling_device" since="6">
401+ <description summary="set the target device of the wl_buffer">
402+ Set the device the compositor should import the dmabufs to for sampling
403+ in the next create or create_immed request.
404+
405+ To avoid race conditions when the compositor removes a device from the
406+ tranches, it is not a protocol error if the device hasn't been advertised
407+ by the compositor in a tranche with the sampling flag, but the import is
408+ likely to fail in that case.
409+
410+ If the client doesn't know a suitable target device, it shouldn't set one,
411+ and the compositor should attempt import on all devices it supports.
412+
413+ If the array is too small to contain a dev_t or larger than required, the
414+ invalid_dev_t_size error will be emitted.
415+ </description>
416+ <arg name="device" type="array" summary="device dev_t value"/>
417+ </request>
418+ </interface>
419+
420+ <interface name="zwp_linux_dmabuf_feedback_v1" version="6">
421+ <description summary="dmabuf feedback">
422+ This object advertises dmabuf parameters feedback. This includes the
423+ preferred devices and the supported formats/modifiers.
424+
425+ The parameters are sent once when this object is created and whenever they
426+ change. The done event is always sent once after all parameters have been
427+ sent. When a single parameter changes, all parameters are re-sent by the
428+ compositor.
429+
430+ Compositors can re-send the parameters when the current client buffer
431+ allocations are sub-optimal. Compositors should not re-send the
432+ parameters if re-allocating the buffers would not result in a more optimal
433+ configuration. In particular, compositors should avoid sending the exact
434+ same parameters multiple times in a row.
435+
436+ The tranche_target_device and tranche_formats events are grouped by
437+ tranches of preference. For each tranche, a tranche_target_device, one
438+ tranche_flags and one or more tranche_formats events are sent, followed
439+ by a tranche_done event finishing the list. The tranches are sent in
440+ descending order of preference. All formats and modifiers in the same
441+ tranche have the same preference.
442+
443+ To send parameters, the compositor sends one main_device event (unless
444+ the client bound version 6 or above), tranches (each consisting of one
445+ tranche_target_device event, one tranche_flags event, tranche_formats
446+ events and then a tranche_done event), then one done event.
447+
448+ With version 6 and above, the compositor must always advertise at least
449+ one tranche with the sampling flag set.
450+ </description>
451+
452+ <request name="destroy" type="destructor">
453+ <description summary="destroy the feedback object">
454+ Using this request a client can tell the server that it is not going to
455+ use the zwp_linux_dmabuf_feedback_v1 object anymore.
456+ </description>
457+ </request>
458+
459+ <event name="done">
460+ <description summary="all feedback has been sent">
461+ This event is sent after all parameters of a zwp_linux_dmabuf_feedback_v1
462+ object have been sent.
463+
464+ This allows changes to the zwp_linux_dmabuf_feedback_v1 parameters to be
465+ seen as atomic, even if they happen via multiple events.
466+ </description>
467+ </event>
468+
469+ <event name="format_table">
470+ <description summary="format and modifier table">
471+ This event provides a file descriptor which can be memory-mapped to
472+ access the format and modifier table.
473+
474+ The table contains a tightly packed array of consecutive format +
475+ modifier pairs. Each pair is 16 bytes wide. It contains a format as a
476+ 32-bit unsigned integer, followed by 4 bytes of unused padding, and a
477+ modifier as a 64-bit unsigned integer. The native endianness is used.
478+
479+ The client must map the file descriptor in read-only private mode.
480+
481+ Compositors are not allowed to mutate the table file contents once this
482+ event has been sent. Instead, compositors must create a new, separate
483+ table file and re-send feedback parameters. Compositors are allowed to
484+ store duplicate format + modifier pairs in the table.
485+ </description>
486+ <arg name="fd" type="fd" summary="table file descriptor"/>
487+ <arg name="size" type="uint" summary="table size, in bytes"/>
488+ </event>
489+
490+ <event name="main_device" deprecated-since="6">
491+ <description summary="preferred main device">
492+ This event advertises the main device that the server prefers to use
493+ when direct scan-out to the target device isn't possible. The
494+ advertised main device may be different for each
495+ zwp_linux_dmabuf_feedback_v1 object, and may change over time.
496+
497+ There is exactly one main device. The compositor must send at least
498+ one preference tranche with tranche_target_device equal to main_device.
499+
500+ Clients need to create buffers that the main device can import and
501+ read from, otherwise creating the dmabuf wl_buffer will fail (see the
502+ zwp_linux_buffer_params_v1.create and create_immed requests for details).
503+ The main device will also likely be kept active by the compositor,
504+ so clients can use it instead of waking up another device for power
505+ savings.
506+
507+ In general the device is a DRM node. The DRM node type (primary vs.
508+ render) is unspecified. Clients must not rely on the compositor sending
509+ a particular node type. Clients cannot check two devices for equality
510+ by comparing the dev_t value.
511+
512+ If explicit modifiers are not supported and the client performs buffer
513+ allocations on a different device than the main device, then the client
514+ must force the buffer to have a linear layout.
515+
516+ With version 6 and above, this event is no longer sent. Clients should
517+ use a device with the sampling flag in the tranches instead.
518+ </description>
519+ <arg name="device" type="array" summary="device dev_t value"/>
520+ </event>
521+
522+ <event name="tranche_done">
523+ <description summary="a preference tranche has been sent">
524+ This event splits tranche_target_device and tranche_formats events into
525+ preference tranches. It is sent after a set of tranche_target_device
526+ and tranche_formats events; it represents the end of a tranche. The
527+ next tranche will have a lower preference.
528+ </description>
529+ </event>
530+
531+ <event name="tranche_target_device">
532+ <description summary="target device">
533+ This event advertises the target device that the server prefers to use
534+ for a buffer created given this tranche. The advertised target device
535+ may be different for each preference tranche, and may change over time.
536+
537+ There is exactly one target device per tranche.
538+
539+ The target device may be a scan-out device, for example if the
540+ compositor prefers to directly scan-out a buffer created given this
541+ tranche. The target device may be a rendering device, for example if
542+ the compositor prefers to texture from said buffer.
543+
544+ The client can use this hint to allocate the buffer in a way that makes
545+ it accessible from the target device, ideally directly. The buffer must
546+ still be accessible from a device with the sampling flag, either through
547+ direct import or a potentially more expensive fallback path. If the
548+ buffer can't be directly imported for sampling, then clients must be
549+ prepared for the compositor changing the tranche priority or making
550+ wl_buffer creation fail (see the zwp_linux_buffer_params_v1.create and
551+ create_immed requests for details).
552+
553+ If the device is a DRM node, the DRM node type (primary vs. render) is
554+ unspecified. Clients must not rely on the compositor sending a
555+ particular node type. Clients cannot check two devices for equality by
556+ comparing the dev_t value.
557+
558+ This event is tied to a preference tranche, see the tranche_done event.
559+ </description>
560+ <arg name="device" type="array" summary="device dev_t value"/>
561+ </event>
562+
563+ <event name="tranche_formats">
564+ <description summary="supported buffer format modifiers">
565+ This event advertises the format + modifier combinations that the
566+ compositor supports.
567+
568+ It carries an array of indices, each referring to a format + modifier
569+ pair in the last received format table (see the format_table event).
570+ Each index is a 16-bit unsigned integer in native endianness.
571+
572+ For legacy support, DRM_FORMAT_MOD_INVALID is an allowed modifier.
573+ It indicates that the server can support the format with an implicit
574+ modifier. When a buffer has DRM_FORMAT_MOD_INVALID as its modifier, it
575+ is as if no explicit modifier is specified. The effective modifier
576+ will be derived from the dmabuf.
577+
578+ A compositor that sends valid modifiers and DRM_FORMAT_MOD_INVALID for
579+ a given format supports both explicit modifiers and implicit modifiers.
580+
581+ Compositors must not send duplicate format + modifier pairs within the
582+ same tranche or across two different tranches with the same target
583+ device and flags.
584+
585+ This event is tied to a preference tranche, see the tranche_done event.
586+
587+ For the definition of the format and modifier codes, see the
588+ zwp_linux_buffer_params_v1.create request.
589+ </description>
590+ <arg name="indices" type="array" summary="array of 16-bit indexes"/>
591+ </event>
592+
593+ <enum name="tranche_flags" bitfield="true">
594+ <entry name="scanout" value="1" since="4">
595+ <description summary="direct scan-out tranche">
596+ The scanout flag is a hint that direct scan-out may be attempted by
597+ the compositor on the target device if the client appropriately
598+ allocates a buffer. How to allocate a buffer that can be scanned out
599+ on the target device is implementation-defined.
600+ </description>
601+ </entry>
602+ <entry name="sampling" value="2" since="6">
603+ <description summary="sampling tranche">
604+ The sampling flag describes that the compositor is able to efficiently
605+ sample from buffers imported to the target device if the client
606+ appropriately allocates a buffer. How to allocate a buffer that can be
607+ efficiently sampled on the target device is implementation defined.
608+ </description>
609+ </entry>
610+ </enum>
611+
612+ <event name="tranche_flags">
613+ <description summary="tranche flags">
614+ This event sets tranche-specific flags. This event is tied to a
615+ preference tranche, see the tranche_done event.
616+ With version 6 and above, the compositor must set at least one flag
617+ in each tranche.
618+ </description>
619+ <arg name="flags" type="uint" enum="tranche_flags" summary="tranche flags"/>
620+ </event>
621+ </interface>
622+
623+</protocol>

Keyboard shortcuts

Single-key shortcuts are on. ctrl k and esc work whatever this says.

ctrl k :
go to a section, branch, tag, file or repository
?
this list
j k
move the row cursor down / up
enter
open the row under the cursor; on Files, a directory opens or closes in place
↑ ↓ ← → home end
in the file tree (focus on a row): previous / next row, close / open a directory or go to its parent / first entry, first / last row. They never open a file
l h
on Files: open a directory or a file / close a directory or go up to its parent, then to the parent page. Elsewhere: into the side panel (on a merge request, its files) / back to the content; there j k move between its controls
g g G
first / last row
/
filter the list; on Files, find a file anywhere in the repository (esc clears, enter opens the best match)
b
switch branch or tag
g s g f g c g b g m g i g r g a
tabs: summary, files, commits, branches & tags, merge requests, issues, releases, actions (when available)
g h
home
w
wide mode: use the whole width of the screen, or not (remembered)
y
copy a permalink pinned to the commit
d u x
diff: split / unified / collapse or expand all
e E
diff: the whole file in view / every file, with the lines the hunks hide
n
merge request: next note in the diff
esc
close a dialog, leave a field

Branches 1

Tags 14

↑↓ moveenter openesc close