Pekka Paalanen wrote:
>> The Vk implementation as well as the application instanciating the Vk
>> would then both be free to choose whatever implementation to talk
>> wayland protocol.
> Ok, yeah, you could invent something like that, but how do you then
> guarantee the strict message ordering r
On Wed, 16 Sep 2020 17:10:49 +0200
Jan Bruns wrote:
> Pekka Paalanen wrote:
>
> >> Would they introduce
> >> structures named like
> >>
> >> VK_STRUCTURE_TYPE_WAYLAND_NOLIBWAYLAND_SURFACE_CREATE_INFO_KHR or
> >> VK_STRUCTURE_TYPE_DIRECTWAYLAND_SURFACE_CREATE_INFO_KHR, in addition to
> >> t
Pekka Paalanen wrote:
>> Would they introduce
>> structures named like
>>
>> VK_STRUCTURE_TYPE_WAYLAND_NOLIBWAYLAND_SURFACE_CREATE_INFO_KHR or
>> VK_STRUCTURE_TYPE_DIRECTWAYLAND_SURFACE_CREATE_INFO_KHR, in addition to
>> the existing VK_STRUCTURE_TYPE_WAYLAND_SURFACE_CREATE_INFO_KHR?
>
> I cann
t; > is not to write a program that uses Wayland in your preferred language,
> > then what is it?
> >
> > What workflow are you referring to?
>
> Well, why was it almost necessary to ask this mailing list about basic
> API usage?
Hi,
I would think that writing la
at workflow are you referring to?
Well, why was it almost necessary to ask this mailing list about basic
API usage?
Thanks to your great tips I was able to get to the point where I can say
I have the option to use the API (this was the motivation: the goal was
to evaluate if there is such
On Sat, 12 Sep 2020 15:24:24 +0200
Jan Bruns wrote:
> Simon Ser:
...
> > I don't know if it's just me, but your e-mails sound like rants and
> > aren't making it very appealing for people to reply to. I think Pekka
> > is being very patient and helpful here, and I'd appreciate if you could
>
El sábado, 12 de septiembre de 2020, Simon Ser
escribió:
>
>
> > To me this looks like the generated C code would frequently make use of
> > unspecified interface versions, so that distro-maintainers would have to
> > intensively take care about the exact version in use for any single app
> > that
Simon Ser:
> Hi,
> wl_display version is hardcoded to 1, because the client retrieves it
> before version negociation can happen.
> wl_registry_bind lets the client specify the version they want to bind
> to.
> wl_surface inherits its version from wl_compositor.
Yes, that's what happens for un
Hi,
On Saturday, September 12, 2020 1:21 PM, Jan Bruns wrote:
> > How to tell libwayland to not attempt to call nonexisting callbacks?
>
> Well, libwayland of course has some work around this issue (there's a
> versioned mashalling function that should apply the version to the
> new-id arg).
>
>
Jan Bruns wrote:
> I've just stumbled upon a more serious question:
>
> registry.bind() doesn't have a version parameter, and also
wl_proxy_add_listener().
>
> Doesn't this mean that an App that doesn't know the latest version of
an interface cannot use libwayland anymore?
>
> How to tell libw
Pekka Paalanen wrote:
> Jan Bruns wrote:
>
>> Ok. I now have an even earlier point of missing knowledge than I
expected:
>>
>> Why does the generated version of wayland-client-protocol.h reference a
>> server object called "wl_registry_interface"?
>
> These interface structures are used both se
On Wed, 9 Sep 2020 17:44:59 +0200
Jan Bruns wrote:
> Ok. I now have an even earlier point of missing knowledge than I expected:
>
> Why does the generated version of wayland-client-protocol.h reference a
> server object called "wl_registry_interface"?
These interface structures are used both s
On Wednesday, 9 September 2020 02:50:21 PDT Pekka Paalanen wrote:
> > Well, the last time I've read some C-language specification many years
> > ago, the one thing that it really made clear was you can count on
> > everything is completely undefined.
>
> Ha, yeah.
C'mon, you know it isn't true.
On 09.09.20 17:44, Jan Bruns wrote:
Ok. I now have an even earlier point of missing knowledge than I
expected:
Why does the generated version of wayland-client-protocol.h reference
a server object called "wl_registry_interface"?
It is (contrary to what me thought, again mixing up the array a
Ok. I now have an even earlier point of missing knowledge than I expected:
Why does the generated version of wayland-client-protocol.h reference a
server object called "wl_registry_interface"?
It makes use of it in
extern const struct wl_interface wl_registry_interface;
static inline stru
On Wed, 9 Sep 2020 15:18:20 +0200
Jan Bruns wrote:
> I'll have to reevaluate the amount of required work now, and maybe I
> could start with simple tests. My guess is there's some parent-child
> process relationship required in order for the fd-passing mechanism to work?
No, no such requiremen
Hallo Pekka,
>> > Unfortunately there are many details that have not yet been written
>> > down in a specification document, which means you need to compare
with
>> > how the C bindings actually work, e.g. what does wayland-scanner do
>> > with the XML. The common catch is that a new_id arg
On Tue, 8 Sep 2020 22:24:16 +0200
Jan Bruns wrote:
> Hallo Pekka,
>
> thanks for that great reply. It made a lot of things much more clear to
> me, but I must admit I'll probably simply give up.
>
> > yes, the application used headers are generated by a bindings-specific
> > tool from the XM
Hallo Pekka,
thanks for that great reply. It made a lot of things much more clear to
me, but I must admit I'll probably simply give up.
> yes, the application used headers are generated by a bindings-specific
> tool from the XML, like wayland-scanner for the traditional C bindings.
> wayland.
On Mon, 7 Sep 2020 16:47:42 +0200
Jan Bruns wrote:
> Hallo!
>
> From the perspective of someone with a non-gcc-supported programming
> language preference, I have problems identifying an outline of steps
> required to support wayland from within an application.
>
> For example, from the huma
Hallo!
From the perspective of someone with a non-gcc-supported programming
language preference, I have problems identifying an outline of steps
required to support wayland from within an application.
For example, from the human readable documentation at
wayland.freedesktop.org, I've learned
21 matches
Mail list logo
