[ANNOUNCE] weston 5.0.0

[Derek Foreman]

This is the official release of weston 5.0.0.

There are a few minor fixes pending that didn't make it in time for the
release, so I think this time I'll follow up with a 5.0.1 in around a
month or so.

For the next major release, I think 3 months until the alpha has worked
ok in the past - anyone with another preference, please speak up!


Derek Foreman (1):
  configure.ac: bump to version 5.0.0 for the official release

Stefan Agner (1):
  compositor-drm: add DPI connector type

git tag 5.0.0

https://wayland.freedesktop.org/releases/weston-5.0.0.tar.xz
MD5: 752a04ce3c65af4884cfac4e57231bdb weston-5.0.0.tar.xz
SHA1: 56b42b1fbea9e120a8127736328e4c71ac781a57 weston-5.0.0.tar.xz
SHA256: 15a23423bcfa45e31e1dedc0cd524ba71e2930df174fde9c99b71a537c4e4caf
weston-5.0.0.tar.xz
SHA512:
b6f97eca014ea47f3de0c5ddd89712f896cd66423d0eb499e1d88d35aab616cef1e735ebb8e0cefd8b60085314b6ec3d56b39d7c4776188bb56d58efc84a52cf
weston-5.0.0.tar.xz

PGP: https://wayland.freedesktop.org/releases/weston-5.0.0.tar.xz.sig



signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] wayland 1.16.0

[Derek Foreman]

This is the official release of wayland 1.16.0.

Since RC2, only a test case for the bug that prompted RC2's existence
has been added.

I'm of the opinion that wayland no longer needs to be released in
lock-step with weston, and should be released as necessary when critical
bug fixes or important changes occur.

At this point I don't see a need to schedule a next wayland release, but
if one hasn't occurred when we near the time weston's ready for its next
major release, we can look at what's landed and decide if there's a need.

If that's a bad idea, please speak up!


Derek Foreman (1):
  configure.ac: bump to version 1.16.0 for the official release

Michal Srb (1):
  tests: Demarshalling of very long array/string lengths.

git tag 1.16.0

https://wayland.freedesktop.org/releases/wayland-1.16.0.tar.xz
MD5: 0c215e53de71d6fb26f7102cdc6432d3 wayland-1.16.0.tar.xz
SHA1: 24c63a5045c653dcfa24efd10fa7c7de89aca9ef wayland-1.16.0.tar.xz
SHA256: 4e72c2b56109ccfb6610d776e465f4ca0af2280c9c2f7d5cc23f0ed2548752f5
wayland-1.16.0.tar.xz
SHA512:
64eca2b1c0bc7913508a5499dae87e2723c712d8024acbb4c77c3c4a6c20de78c10704ae9827fd034116ca540a547aeec28c5a1e3bd382b23f85231424b0f49c
wayland-1.16.0.tar.xz

PGP: https://wayland.freedesktop.org/releases/wayland-1.16.0.tar.xz.sig



signature.asc
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] input: Update to-be-restored focus when unfocused

[Derek Foreman]

On 2018-08-24 12:23 PM, Jamey Sharp wrote:
> For what it's worth, I'm happy to use backported patches. I just hope
> this gets addressed upstream eventually.
> 
> It's a little more than just cosmetic if you have a graphical
> application that can be driven purely by keyboard, and sometimes you
> don't have a working pointer input device so you can't get focus back
> after a VT switch. I grant that's a somewhat niche use case, but it's
> the one I'm dealing with... :-)

Sorry if it seemed I was dismissing this work entirely.  This bug has
been annoying me for quite some time and I hadn't looked into it at all
myself. For my use case, I can use the keyboard focus switch shortcut to
focus something, so it hasn't been a showstopper.

I think we're going to do a weston 5.0.1 in a month or so, and this will
be among the fixes it contains. :)

> I was confused about the state of these patches too, because I didn't
> see the original mails. Hopefully next week I can test the combination
> of Quentin's revert+fix pair with my patch and make sure it passes the
> tests I set up.

That would be great!

> On that note, I would offer my test framework upstream, except I set up
> an entire qemu image using NixOS to test this, and that seems a little
> heavyweight. I can't think of an easier way to test drm-backend stuff
> though...

Would still be interesting to take a look at, I think.

Thanks,
Derek

> Jamey
> 
> On Fri, Aug 24, 2018 at 7:11 AM, Derek Foreman
>  > wrote:
> 
> On 2018-08-16 02:33 AM, Quentin Glidic wrote:
> > On 8/16/18 5:24 AM, Peter Hutterer wrote:
> >> On Fri, Aug 10, 2018 at 12:55:42PM -0500, Derek Foreman wrote:
> >>> On 2018-08-02 03:32 AM, Quentin Glidic wrote:
>  On 8/2/18 10:29 AM, Quentin Glidic wrote:
> > From: Quentin Glidic  >
> >
> > If we start a special (grabbing) client when Weston is
> unfocused, it
> > would lose focus when coming back to Weston.
> >
> > A first attempt to fix this was
> > 85d55540cb64bf97a08b40f79dc66843f8295d3b
> > but it messed with VT switching.
> >
> > This fix just updates the saved focus, so when Weston gets focused
> > back,
> > it will focus the correct client.
> >
> > Signed-off-by: Quentin Glidic  >
> > ---
> >
> > Sorry for the delay, I hoped I could make a Gitlab MR but sadly it
> > didn’t happen yet. :-)
> >
> > I think this patch won’t conflict with VT switching, and it does
> > fix the
> > issue I had initially.
> >>>
> >>> I'm a bit confused as to where we're at with this.
> >>>
> >>> How did the reverted patch "mess with" or "conflict with" VT
> switching?
> >>
> >> it ended up always setting the keyboard focus to NULL on VT switch
> >> (due to
> >> how libinput devices are handled), so on vt switch back you had
> no focus.
> >>  
> >>> Is it intended that these two patches be applied, and then
> Jamey's patch
> >>> (marked as "superseded" in patchwork) be applied on top to
> resolve the
> >>> loss of focus on VT switch away/back?
> >>
> >> AIUI, these two need supersede Jamey's patchl but I'm not 100%
> sure on
> >> that,
> >> sorry.
> >>
> >> Cheers,
> >>     Peter
> >>
> >>>
> >>> Thought this might be important to land before the release, but
> it's not
> >>> terribly clear what it actually fixes.  I'd assumed it was the
> VT switch
> >>> thing, but that remains unresolved.
> >>>
> >>> Help? :)
> > Sorry for the confusion. This (second) patch is a cleaner fix of the
> > issue that was “fixed” by the reverted commit. Then on top of it,
> you’ll
> > have to apply Jamey’s patch, which is an independent issue+fix (which
> > the old fix conflicted with). I’m not sure why it was marked
> > superseeded, maybe Patchwork detecting my patch as a reply?
> >
> 
> Thanks guys.  Due to hilariously misconfigured inbox filters I didn't
> catch these replies until today.  Sorry.
> 
> I think the VT switch problem has been around for at least 1 release
> now, possibly a few more, so I think it's ok to release with the long
> standing (mostly cosmetic) bug, and deal with these fixes shortly after.
> 
> Thanks again,
> Derek
> 
> 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] input: Update to-be-restored focus when unfocused

[Jamey Sharp]

For what it's worth, I'm happy to use backported patches. I just hope this
gets addressed upstream eventually.

It's a little more than just cosmetic if you have a graphical application
that can be driven purely by keyboard, and sometimes you don't have a
working pointer input device so you can't get focus back after a VT switch.
I grant that's a somewhat niche use case, but it's the one I'm dealing
with... :-)

I was confused about the state of these patches too, because I didn't see
the original mails. Hopefully next week I can test the combination of
Quentin's revert+fix pair with my patch and make sure it passes the tests I
set up.

On that note, I would offer my test framework upstream, except I set up an
entire qemu image using NixOS to test this, and that seems a little
heavyweight. I can't think of an easier way to test drm-backend stuff
though...

Jamey

On Fri, Aug 24, 2018 at 7:11 AM, Derek Foreman <
derek.foreman.sams...@gmail.com> wrote:

> On 2018-08-16 02:33 AM, Quentin Glidic wrote:
> > On 8/16/18 5:24 AM, Peter Hutterer wrote:
> >> On Fri, Aug 10, 2018 at 12:55:42PM -0500, Derek Foreman wrote:
> >>> On 2018-08-02 03:32 AM, Quentin Glidic wrote:
>  On 8/2/18 10:29 AM, Quentin Glidic wrote:
> > From: Quentin Glidic 
> >
> > If we start a special (grabbing) client when Weston is unfocused, it
> > would lose focus when coming back to Weston.
> >
> > A first attempt to fix this was
> > 85d55540cb64bf97a08b40f79dc66843f8295d3b
> > but it messed with VT switching.
> >
> > This fix just updates the saved focus, so when Weston gets focused
> > back,
> > it will focus the correct client.
> >
> > Signed-off-by: Quentin Glidic 
> > ---
> >
> > Sorry for the delay, I hoped I could make a Gitlab MR but sadly it
> > didn’t happen yet. :-)
> >
> > I think this patch won’t conflict with VT switching, and it does
> > fix the
> > issue I had initially.
> >>>
> >>> I'm a bit confused as to where we're at with this.
> >>>
> >>> How did the reverted patch "mess with" or "conflict with" VT switching?
> >>
> >> it ended up always setting the keyboard focus to NULL on VT switch
> >> (due to
> >> how libinput devices are handled), so on vt switch back you had no
> focus.
> >>
> >>> Is it intended that these two patches be applied, and then Jamey's
> patch
> >>> (marked as "superseded" in patchwork) be applied on top to resolve the
> >>> loss of focus on VT switch away/back?
> >>
> >> AIUI, these two need supersede Jamey's patchl but I'm not 100% sure on
> >> that,
> >> sorry.
> >>
> >> Cheers,
> >> Peter
> >>
> >>>
> >>> Thought this might be important to land before the release, but it's
> not
> >>> terribly clear what it actually fixes.  I'd assumed it was the VT
> switch
> >>> thing, but that remains unresolved.
> >>>
> >>> Help? :)
> > Sorry for the confusion. This (second) patch is a cleaner fix of the
> > issue that was “fixed” by the reverted commit. Then on top of it, you’ll
> > have to apply Jamey’s patch, which is an independent issue+fix (which
> > the old fix conflicted with). I’m not sure why it was marked
> > superseeded, maybe Patchwork detecting my patch as a reply?
> >
>
> Thanks guys.  Due to hilariously misconfigured inbox filters I didn't
> catch these replies until today.  Sorry.
>
> I think the VT switch problem has been around for at least 1 release
> now, possibly a few more, so I think it's ok to release with the long
> standing (mostly cosmetic) bug, and deal with these fixes shortly after.
>
> Thanks again,
> Derek
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] input: Update to-be-restored focus when unfocused

[Derek Foreman]

On 2018-08-16 02:33 AM, Quentin Glidic wrote:
> On 8/16/18 5:24 AM, Peter Hutterer wrote:
>> On Fri, Aug 10, 2018 at 12:55:42PM -0500, Derek Foreman wrote:
>>> On 2018-08-02 03:32 AM, Quentin Glidic wrote:
 On 8/2/18 10:29 AM, Quentin Glidic wrote:
> From: Quentin Glidic 
>
> If we start a special (grabbing) client when Weston is unfocused, it
> would lose focus when coming back to Weston.
>
> A first attempt to fix this was
> 85d55540cb64bf97a08b40f79dc66843f8295d3b
> but it messed with VT switching.
>
> This fix just updates the saved focus, so when Weston gets focused
> back,
> it will focus the correct client.
>
> Signed-off-by: Quentin Glidic 
> ---
>
> Sorry for the delay, I hoped I could make a Gitlab MR but sadly it
> didn’t happen yet. :-)
>
> I think this patch won’t conflict with VT switching, and it does
> fix the
> issue I had initially.
>>>
>>> I'm a bit confused as to where we're at with this.
>>>
>>> How did the reverted patch "mess with" or "conflict with" VT switching?
>>
>> it ended up always setting the keyboard focus to NULL on VT switch
>> (due to
>> how libinput devices are handled), so on vt switch back you had no focus.
>>  
>>> Is it intended that these two patches be applied, and then Jamey's patch
>>> (marked as "superseded" in patchwork) be applied on top to resolve the
>>> loss of focus on VT switch away/back?
>>
>> AIUI, these two need supersede Jamey's patchl but I'm not 100% sure on
>> that,
>> sorry.
>>
>> Cheers,
>>     Peter
>>
>>>
>>> Thought this might be important to land before the release, but it's not
>>> terribly clear what it actually fixes.  I'd assumed it was the VT switch
>>> thing, but that remains unresolved.
>>>
>>> Help? :)
> Sorry for the confusion. This (second) patch is a cleaner fix of the
> issue that was “fixed” by the reverted commit. Then on top of it, you’ll
> have to apply Jamey’s patch, which is an independent issue+fix (which
> the old fix conflicted with). I’m not sure why it was marked
> superseeded, maybe Patchwork detecting my patch as a reply?
> 

Thanks guys.  Due to hilariously misconfigured inbox filters I didn't
catch these replies until today.  Sorry.

I think the VT switch problem has been around for at least 1 release
now, possibly a few more, so I think it's ok to release with the long
standing (mostly cosmetic) bug, and deal with these fixes shortly after.

Thanks again,
Derek
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v3] unstable/drm-lease: DRM lease protocol support

[Marius-cristian Vlad]

On Fri, 2018-08-24 at 11:58 +0200, Philipp Zabel wrote:
> Hi Marius,
> 
> On Fri, 2018-08-24 at 09:21 +, Marius-cristian Vlad wrote:
> > On Fri, 2018-08-24 at 10:57 +0200, Philipp Zabel wrote:
> 
> [...]
> > > > yes, sending one event per connector is a good design, but see
> > > > below if we actually might want to extend that to creating an
> > > > object per connector with "per-attribute" events for pieces of
> > > > information.
> > > 
> > > And object would allow handling both cases the same way when
> > > building
> > > the lease request.
> > 
> > To make sure I understand this "object" leasing. Instead of
> > advertising
> > connectors this way:
> > 
> > 
> >   
> > This event advertises a leasable connector. This allows
> > the
> >    client to
> > choose which connector the compositor should lease. It can
> > either
> > use connector name, monitor name, or if that's not
> > sufficient
> > to parse
> > EDID blob.
> >   
> >    > />
> >   
> >   
> >   
> >   
> >   
> > 
> > 
> > We do something like this:
> > 
> > 
> >   
> > This event advertises a leasable connector object.
> >   
> >    > interface="zwp_kms_lease_connector_v1"
> >   summary="the new temporary" />
> > 
> > 
> > 
> > Then that interface is used to query info (like
> > EDID/conn_name/monitor
> > name)
> 
> Yes, that is my understanding as well.
> 
> I expect that for all currently known use cases the connector name
> (like
> xdg_output.name) and the monitor vendor / product id / serial string
> should be sufficient. Maybe the native resolution and refresh rate
> could
> be useful as well.
> 
> I would suggest leaving the raw EDID out for now, a request for it
> can
> be added later to zwp_kms_lease_connector_v1, if necessary. It won't
> be
> possible to pass otentially huge complete EDIDs in an array argument.
> 
> > and using that information to ask/revoke the lease (based on
> > either connector name, or based on EDID)?
> 
> I imagine that object to be passed to the lease request's
> add_connector
> request directly:
> 
>   
> ...
> 
>       interface="zwp_kms_lease_connector_v1"
>    summary="a leasable connector to be added to the lease
> request"/>
> 
>   
> 
> That way there is no need for separate requests
> "add_connector_by_name",
> "add_connnector_by_vendor_product_serial" etc.
> 
> The same could potentially be done later with a
> "zwp_kms_lease_plane_v1"
> object and "add_plane" request.

Got it. Will give it a test and see how it goes.


> 
> regards
> Philipp
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v3] unstable/drm-lease: DRM lease protocol support

[Philipp Zabel]

Hi Marius,

On Fri, 2018-08-24 at 09:21 +, Marius-cristian Vlad wrote:
> On Fri, 2018-08-24 at 10:57 +0200, Philipp Zabel wrote:
[...]
> > > yes, sending one event per connector is a good design, but see
> > > below if we actually might want to extend that to creating an
> > > object per connector with "per-attribute" events for pieces of
> > > information.
> > 
> > And object would allow handling both cases the same way when building
> > the lease request.
> 
> To make sure I understand this "object" leasing. Instead of advertising
> connectors this way:
> 
> 
>   
> This event advertises a leasable connector. This allows the
>client to
> choose which connector the compositor should lease. It can
> either
> use connector name, monitor name, or if that's not sufficient
> to parse
> EDID blob.
>   
>   
>   
>   
>   
>   
>   
> 
> 
> We do something like this:
> 
> 
>   
> This event advertises a leasable connector object.
>   
>    interface="zwp_kms_lease_connector_v1"
>   summary="the new temporary" />
> 
> 
> 
> Then that interface is used to query info (like EDID/conn_name/monitor
> name)

Yes, that is my understanding as well.

I expect that for all currently known use cases the connector name (like
xdg_output.name) and the monitor vendor / product id / serial string
should be sufficient. Maybe the native resolution and refresh rate could
be useful as well.

I would suggest leaving the raw EDID out for now, a request for it can
be added later to zwp_kms_lease_connector_v1, if necessary. It won't be
possible to pass otentially huge complete EDIDs in an array argument.

> and using that information to ask/revoke the lease (based on
> either connector name, or based on EDID)?

I imagine that object to be passed to the lease request's add_connector
request directly:

  
...

  

  

That way there is no need for separate requests "add_connector_by_name",
"add_connnector_by_vendor_product_serial" etc.

The same could potentially be done later with a "zwp_kms_lease_plane_v1"
object and "add_plane" request.

regards
Philipp
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v3] unstable/drm-lease: DRM lease protocol support

[Marius-cristian Vlad]

On Fri, 2018-08-24 at 10:57 +0200, Philipp Zabel wrote:
> Hi Pekka,
> 
> On Thu, 2018-08-23 at 14:39 +0300, Pekka Paalanen wrote:
> > Sorry for the potentially duplicate email, my MUA messed up the CC
> > list
> > on the first go.
> > 
> > 
> > On Thu, 23 Aug 2018 08:41:30 +0200
> > Philipp Zabel  wrote:
> > 
> > > Hi,
> > > 
> > > On Wed, 2018-08-22 at 11:12 +, Marius-cristian Vlad wrote:
> > > [...]  
> > > > > Why not just send the connectors one by one, a single event
> > > > > with all
> > > > > relevant information for each?
> > 
> > Hi,
> > 
> > yes, sending one event per connector is a good design, but see
> > below if
> > we actually might want to extend that to creating an object per
> > connector with "per-attribute" events for pieces of information.
> 
> One reason for creating an object would be that in some cases (like
> VR)
> the client will want to match on vendor/model/serial from EDID, but
> in
> other scenarios EDID data might not even be available.
> When leasing a DPI or LVDS panel without EDID information, the
> connector
> would have to be identified via the connector name, for example.
> 
> And object would allow handling both cases the same way when building
> the lease request.

To make sure I understand this "object" leasing. Instead of advertising
connectors this way:


  
This event advertises a leasable connector. This allows the
   client to
choose which connector the compositor should lease. It can
either
use connector name, monitor name, or if that's not sufficient
to parse
EDID blob.
  
  
  
  
  
  
  


We do something like this:


  
This event advertises a leasable connector object.
  
  



Then that interface is used to query info (like EDID/conn_name/monitor
name) and using that information to ask/revoke the lease (based on
either connector name, or based on EDID)?

Is this the right assumption?

> 
> > > > Hmm, okay, I'll try do that. 
> > > 
> > > I'm wondering what should be used to identify a connector to a
> > > hypothetical Vulkan VK_EXT_acquire_wayland_display extension, or
> > > to
> > > other APIs that may request leases on the application's behalf.
> > > 
> > > What could be passed into a Vulkan function to request the lease
> > > and
> > > retrieve the corresponding VkDisplayKHR object? wl_display and
> > > make/model/serial strings? wl_display and drm connector name?
> > > Or is there need for an object describing a leasable connector,
> > > similar to wl_output?  
> > 
> > One certainly cannot rely on wl_output, because that will not be
> > present for outputs that are not currently used as part of the
> > desktop.
> > IOW, HMDs are likely never exposed as a wl_output.
> 
> Understood, it would have to be a new object. There could be more of
> them than wl_outputs, and they wouldn't carry the same information:
> output geometry obviously has no place here. But there is some
> overlap.
> The wl_output geometry event also contains "make" and "model"
> arguments name="connector"><   
>   
>   < 
> This event advertises a leasable connector. This allows the
> client to<
> choose which connector the compositor should lease. It can
> either<
> use connector name, monitor name, or if that's not sufficient
> to parse<   
> EDID
> blob.<   
> 
>   <
>  
>    /><
>   <  
>   <
>   <
>   < 
>   <
> <
>  
> (but is missing product id or serial). And I notice that
> zxdg_output_v1
> already has a "name" event that likely contains the connector name.
> Maybe the leasable connector object should report all of these as
> events.
> 
> > > Or should the leasing be done by the application itself, outside
> > > of
> > > Vulkan, and just the zwp_kms_lease_v1 object be passed in?  
> > 
> > These are good questions, I hope answers will be found for what the
> > Vulkan and other APIs will actually need for advertising what they
> > need
> > to advertise.
> 
> I suppose this is something that should be discussed on the Vulkan
> side
> first? Given we'd need a new extension there anyway, maybe the
> solution
> is not making this wayland specific at all and just adding a way to
> import the 

Re: [PATCH wayland-protocols v3] unstable/drm-lease: DRM lease protocol support

[Philipp Zabel]

Hi Pekka,

On Thu, 2018-08-23 at 14:39 +0300, Pekka Paalanen wrote:
> Sorry for the potentially duplicate email, my MUA messed up the CC list
> on the first go.
> 
> 
> On Thu, 23 Aug 2018 08:41:30 +0200
> Philipp Zabel  wrote:
> 
> > Hi,
> > 
> > On Wed, 2018-08-22 at 11:12 +, Marius-cristian Vlad wrote:
> > [...]  
> > > > Why not just send the connectors one by one, a single event with all
> > > > relevant information for each?
> 
> Hi,
> 
> yes, sending one event per connector is a good design, but see below if
> we actually might want to extend that to creating an object per
> connector with "per-attribute" events for pieces of information.

One reason for creating an object would be that in some cases (like VR)
the client will want to match on vendor/model/serial from EDID, but in
other scenarios EDID data might not even be available.
When leasing a DPI or LVDS panel without EDID information, the connector
would have to be identified via the connector name, for example.

And object would allow handling both cases the same way when building
the lease request.

> > > Hmm, okay, I'll try do that. 
> > 
> > I'm wondering what should be used to identify a connector to a
> > hypothetical Vulkan VK_EXT_acquire_wayland_display extension, or to
> > other APIs that may request leases on the application's behalf.
> > 
> > What could be passed into a Vulkan function to request the lease and
> > retrieve the corresponding VkDisplayKHR object? wl_display and
> > make/model/serial strings? wl_display and drm connector name?
> > Or is there need for an object describing a leasable connector,
> > similar to wl_output?  
> 
> One certainly cannot rely on wl_output, because that will not be
> present for outputs that are not currently used as part of the desktop.
> IOW, HMDs are likely never exposed as a wl_output.

Understood, it would have to be a new object. There could be more of
them than wl_outputs, and they wouldn't carry the same information:
output geometry obviously has no place here. But there is some overlap.
The wl_output geometry event also contains "make" and "model" arguments
(but is missing product id or serial). And I notice that zxdg_output_v1
already has a "name" event that likely contains the connector name.
Maybe the leasable connector object should report all of these as
events.

> > Or should the leasing be done by the application itself, outside of
> > Vulkan, and just the zwp_kms_lease_v1 object be passed in?  
> 
> These are good questions, I hope answers will be found for what the
> Vulkan and other APIs will actually need for advertising what they need
> to advertise.

I suppose this is something that should be discussed on the Vulkan side
first? Given we'd need a new extension there anyway, maybe the solution
is not making this wayland specific at all and just adding a way to
import the leased DRM fd.

> > > > Especially EDID info would be most useful for finding the right VR
> > > > headset.  
> 
> Sharing EDID could be tricky mechanically. If we assume that an average
> EDID blob is 256 bytes, it would be small enough to pass "inline" in
> Wayland, e.g. as a wl_array argument on an event. But since we want to
> provide it for all leasable connectors, the burst of data could grow
> bigger than the buffers in libwayland, and we start relying on the
> kernel socket buffers which are much larger usually.

I'm not sure if pushing the complete EDID is necessary. Maybe there
should be an EDID request if preparsed vendor/product/serial or
connector name are good enough to identify the to-be-leased connector in
most cases.

> Maybe it's ok to start with a wl_array while we are still in unstable
> protocol, but this question may need to be revisited in the future.
> 
> Is there a defined upper limit on EDID size?

EDID contains an 8-bit number of extension blocks, there should be an
upper limit of about 32 KiB.

> Btw. since we may need to share EDID, and we may need applications to
> parse EDID to dig out what they need, I believe there will be a demand
> for a library to do that. Does any such exist already?

I'm not sure if there is a commonly used one.

[...]
> The client should not receive "all" the data from the compositor
> via Wayland, but only the bits it needs to make the decision whether to
> attempt leasing a connector or not.

Seconded, the protocol should contain just enough to make a decision to
lease.

> Modes are part of EDID, so if we send EDID, I think that's good enough.
> After all, we want to describe the monitor/HMD foremost, not what the
> kernel or the compositor have decided it can do (e.g. add standard
> modes the EDID might miss, or prune modes that cannot be used).

What about legacy LVDS and DPI displays that have no EDID information?
I expect those would be matched by connector name, but maybe there are
also use cases where somebody would select a connector to lease
depending on its native resolution or refresh rate.

> That data does not need to be compl

Re: [PATCH wayland-protocols v3] unstable/drm-lease: DRM lease protocol support

[Pekka Paalanen]

On Thu, 23 Aug 2018 15:12:03 +
Marius-cristian Vlad  wrote:

> On Thu, 2018-08-23 at 14:39 +0300, Pekka Paalanen wrote:

> > > > > Especially EDID info would be most useful for finding the right
> > > > > VR
> > > > > headset.    
> > 
> > Sharing EDID could be tricky mechanically. If we assume that an
> > average
> > EDID blob is 256 bytes, it would be small enough to pass "inline" in
> > Wayland, e.g. as a wl_array argument on an event. But since we want
> > to
> > provide it for all leasable connectors, the burst of data could grow
> > bigger than the buffers in libwayland, and we start relying on the
> > kernel socket buffers which are much larger usually.
> > 
> > Maybe it's ok to start with a wl_array while we are still in unstable
> > protocol, but this question may need to be revisited in the future.
> > 
> > Is there a defined upper limit on EDID size?
> > 
> > Btw. since we may need to share EDID, and we may need applications to
> > parse EDID to dig out what they need, I believe there will be a
> > demand
> > for a library to do that. Does any such exist already?  
> 
> Isn't this overkill? Asking the client to parse that blob?
> 
> Wouldn't make more sense to add the fields Philipp mentions
> (manufacturer ID/product code) fields in drm_edid? The compositor
> already parses the EDID to provide/supply a serial number/monitor name.
> 
> If the client can ask the kernel (through the leased fd) and chooses
> what mode it wants, then what would be the point to send the whole
> EDID? 

As I mentioned below, I don't know if we *need* to send EDID. It all
depends on what the applications will need for making the decision to
attempt leasing.

A problem with sending just specific parsed fields of EDID instead of
the blob is that we need to update the protocol if new very useful
fields appear in EDID.

It's a trade-off, both ways can work.

For the record, I think on X11 EDID is already exposed to clients, so
VR runtimes might expect it to be available. Of course, one can get it
after creating the lease, too, so not including it in the leasing
protocol will not prohibit clients from getting it. It just takes more
effort on the client.


Thanks,
pq


pgpwRIIgGFava.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v5 03/14] libweston: add weston_debug API and implementation

[Pekka Paalanen]

On Thu, 23 Aug 2018 17:53:07 +0100
Daniel Stone  wrote:

> Hi Pekka,
> 
> On Mon, 6 Aug 2018 at 12:16, Pekka Paalanen  wrote:
> > On Fri, 20 Jul 2018 20:03:24 +0100 Daniel Stone  
> > wrote:  
> > > +/** Format current time as a string
> > > + * and append the debug scope name to it
> > > + *
> > > + * \param scope[in] debug scope.
> > > + * \param buf[out] Buffer to store the string.
> > > + * \param len Available size in the buffer in bytes.
> > > + * \return \c buf
> > > + *
> > > + * Reads the current local wall-clock time and formats it into a string.
> > > + * and append the debug scope name to it.
> > > + * The string is nul-terminated, even if truncated.
> > > + */
> > > +WL_EXPORT char *
> > > +weston_debug_scope_timestamp(struct weston_debug_scope *scope,
> > > +  char *buf, size_t len)
> > > +{
> > > + struct timeval tv;
> > > + struct tm *bdt;
> > > + char string[128];
> > > + size_t ret = 0;
> > > +
> > > + gettimeofday(&tv, NULL);
> > > +
> > > + bdt = localtime(&tv.tv_sec);
> > > + if (bdt)
> > > + ret = strftime(string, sizeof string,
> > > +"%Y-%m-%d %H:%M:%S", bdt);
> > > +
> > > + if (ret > 0)
> > > + snprintf(buf, len, "[%s.%03ld][%s]", string,
> > > +  tv.tv_usec / 1000, scope->name);
> > > + else
> > > + snprintf(buf, len, "[?][%s]", scope->name);
> > > +
> > > + return buf;
> > > +}  
> >
> > realized something when looking at the "log" debug scope patch:
> > weston_debug_scope_timestamp() should probably be resilient against
> > scope == NULL, all the other functions already are.
> >
> > weston_log gets initialized early, but the log debug scope gets
> > initialized after the compositor. If something logs something between
> > those two...  
> 
> The users introduced in this patchset already check if the scope is
> enabled, which bails out if the scope is NULL. Given that, and that I
> can't see a sensible behaviour if the scope is NULL, I'm inclined to
> add an assert(scope) at the top of the function as well as
> documentation. Does that seem reasonable? Would assert(scope) be
> better or assert(weston_debug_scope_is_enabled(scope))?

Hi Daniel,

after "compositor: offer logs via weston-debug",
main.c:custom_handler() will call weston_debug_scope_timestamp()
unchecked.

Relying on libwayland not logging anything until the debug scope has
been set up seems a bit too fragile to me.

We could forbid calling weston_debug_scope_timestamp() with NULL scope,
but I think it would be easier if it just accepted NULL by doing
whatever non-crashy. That would be easier for developers. It could
simply replace the scope name with "unknown" for instance. The
resulting string will probably never be used, so it might just make an
empty string too.



On another matter, I've been wondering if storing the debug scopes in
weston_compositor is a good thing. We have the logger initialized
earlier, and quite a lot might happen before weston_compositor is
created. Also the idea of a circular buffer for after-the-fact
reporting might benefit from having debug scopes set up early, and the
command line argument to enable debug scopes from launch.


Thanks,
pq


pgpDaYjKBfyyN.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel