Re: [ANNOUNCE] Weston 13.0.1

[Marius Vlad]

Hi all,

Further update on this, some folks reported that 13.0.1 tag was wrong,
which prompted a new 13.0.2 point release.

I managed to trip a few issues with the release script again and that
one is botched as well. I've sent out a recent announcement for 13.0.3
so please use that one as the latest stable point release.

Apologies if this caused issues/inconsistencies, but there were some
cumulative factors that lead to this.

On Tue, Apr 23, 2024 at 08:07:41PM +0300, Marius Vlad wrote:
> Hi all,
> 
> Someone pointed out that the tag was wrong, pointing apparently to
> main branch. Had to delete the tag and re-create it. Should now point
> correctly. All links are the same, with the same files.
> 
> Thanks for heads-up Dylan!
> 
> On Tue, Apr 23, 2024 at 06:55:45PM +0300, Marius Vlad wrote:
> > Hi all,
> > 
> > Weston 13.0.1, a bug fix release for 13.0.0 has been released.
> > 
> > Full changelog below:
> > 
> > Arnaud Vrac (3):
> >   desktop-shell: clamp view alpha correctly
> >   desktop-shell: set proper curtain size when no output is created yet
> >   clients/desktop-shell: fix crash on init when panel is disabled
> > 
> > Derek Foreman (3):
> >   gl-renderer: apply output transform before readback in repaint
> >   libweston: Clip damage to paint node visible region
> >   libweston/backends: Move damage flush into backends
> > 
> > Jeffy Chen (2):
> >   renderer-gl: Fix wrong stride error when reading pixels
> >   desktop-shell: Avoid using maximized size in fullscreen state
> > 
> > Marius Vlad (3):
> >   backend-pipewire: Move region initialization at the start
> >   libweston: Add paint node destruction into weston_layer_entry_remove()
> >   build: bump to version 13.0.1 for the point release
> > 
> > Michael Olbrich (1):
> >   ivi-shell: clear seat focus if necessary when a surface is destroyed
> > 
> > Philipp Zabel (1):
> >   libweston-desktop: Work around crash when opening popup menu
> > 
> > Ray Smith (1):
> >   backend-drm: fix confused fallback format handling
> > 
> > Robert Mader (2):
> >   backend-drm: Don't force non-opaque overlays to primary plane
> >   backend-drm: Sort planes by faked zpos
> > 
> > Wujian Sun (1):
> >   libweston-desktop: Fix weston crash when lost the shsurf
> > 
> > git tag: 13.0.1
> > 
> > https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz
> > SHA256: ea1566ab4f5ffce7e9fd4f7a1fca5b30caae4d50023bf459213994094e02b29a  
> > weston-13.0.1.tar.xz
> > SHA512: 
> > 4a0fd0b1aec823219421d701030bc534576be64b71ede70c7d33f131e9e64c0e0dc209e62f75cecb9368df7604c1d5b2321932eccc818b529d246ec2e3114122
> >   weston-13.0.1.tar.xz
> > PGP:
> > https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz.sig
> > 
> 
> 




signature.asc
Description: PGP signature

[ANNOUNCE] weston 13.0.3

[Marius Vlad]

Hi all,

Due to a few issues (script missing to account for git log @upstream..
command, glab creating automatically tags with the default main branch when 
not find a remote tag, and me not having a branch entry in the git config), 
it made it so that 13.0.1 and 13.0.2 point releases were released based 
on the main branch rather than the correct, 13 branch.

For the 13.0.1 point release I assumed that I could get away with it
just by deleting and re-creating, but apparently some mirrors were quick
to pick up that, and the recent fdo update made it so that people hit
that mirror instead of fdo and managed use the wrong tag.

That required a new 13.0.2 point release, but because I dismissed the
initial issue, assuming that it was just something I might have done
temporarily, I hit this again.

The 13.0.2 release is still available, but now states the same thing as
here, and that it is broken and recommends everyone to use the latest one, 
13.0.3.

I'm including the changelog from 13.0.1 until now (there no new changes
just the meson.build bumps and a fix for CI to be able to do the release), 
but here there are:

Marius Vlad (2):
  build: bump to version 13.0.2 for the point release
  build: bump to version 13.0.3 for the point release

Pekka Paalanen (1):
  CI: work around LeakSanitizer crashes with use_tls=0

git tag: 13.0.3

https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.3/downloads/weston-13.0.3.tar.xz
SHA256: 27f68d96e3b97d98daadef13a202356524924fa381418fa6716b9136ef099093  
weston-13.0.3.tar.xz
SHA512: 
60e655b57cf418902ec6e4371883354165241d9a99a712aabe2165e11ac190dec22836fd885f5178def5416dc5f00e70042b022c96a8e0aa74827bbd4563f9cb
  weston-13.0.3.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.3/downloads/weston-13.0.3.tar.xz.sig



signature.asc
Description: PGP signature

Re: Full-motion zero-copy screen capture in Weston

[Marius Vlad]

Hi,

Note that systemd-udev will not work in a container. That usually
has the side effect of libinput not working either.

On Tue, Jun 04, 2024 at 08:33:48PM +, Hoosier, Matt wrote:
> Tactical question: I somehow missed until this point that the remote and 
> pipewire plugins will only run if the DRM backend is being used.
> 
> But the DRM backend *really* doesn't want to start nowadays unless you're 
> running on a system with seatd and/or logind available. Toolbox [1] is the de 
> facto way to develop on bleeding edge copies of components these days. But it 
> logind and seatd aren't exposed into it.
> 
> How do Weston people interactively develop on the Weston DRM backend nowadays?
With either seatd or logind. I suspect people use containers to build
but run it on the device.

> 
> [1] https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/
> 
> > -Original Message-
> > From: Pekka Paalanen 
> > Sent: Tuesday, June 4, 2024 3:20 AM
> > To: Hoosier, Matt 
> > Cc: s...@cmpwn.com; cont...@emersion.fr; Marius Vlad
> > ; wayland-devel@lists.freedesktop.org
> > Subject: Re: Full-motion zero-copy screen capture in Weston
> > 
> > On Mon, 3 Jun 2024 17:57:18 +
> > "Hoosier, Matt"  wrote:
> > 
> > > > What do you mean you can capture all virtual machines with KMS
> > > > writeback?
> > > >
> > > > What's the architecture there? How do virtual machines access KMS
> > > > hardware? Why would Weston be able to capture their outputs at all?
> > > >
> > >
> > > I hope to have more to say about this shortly.
> > 
> > I'm interested because I worry whether it will work. I don't see how it 
> > could
> > work with the traditional display controllers and DRM drivers.
> > 
> > Maybe some kind of hardware assisted plane "leasing" that works around the
> > DRM KMS software model limitations?
> > 
> > > > The disadvantage is that buffer allocations are accounted to the
> > > > compositor (which can manage its own memory consumption, sure), and
> > > > either the compositor allocates a new buffer for every frame
> > > > (possibly serious overhead) or it needs to wait for all consumers to
> > > > tell that they are done with the buffer before it can be used again.
> > > > Clients might hold on to the buffer indefinitely or just a little
> > > > too long, which is the risk.
> > >
> > > It seems to me this would be a risk of the existing Pipewire backend,
> > > no? At least, if I understood the buffering model of the dmabuf MR
> > > that Marius linked earlier.
> > >
> > 
> > I haven't looked at any of that, so I can't say. I don't know if pipewire 
> > is only
> > allocate-send-forget, or does it include consumers signalling they are done 
> > to
> > allow re-use as well. Or maybe the sources trust that rotating N buffers is
> > always enough, and if a sink needs the data for longer, it will make a copy 
> > in
> > time.
> > 
> > It's a trade-off. Sometimes the overhead of allocate-send-forget with the 
> > risk
> > of OOM (KMS writeback might require a specific type of memory that could be
> > scarce), maybe even with an added copy to avoid exhausting writeback-
> > capable memory, may be justified.
> > 
> > 
> > Thanks,
> > pq


signature.asc
Description: PGP signature

Re: Full-motion zero-copy screen capture in Weston

[Marius Vlad]

Hi again,

The MR I'd like to link is actually at 
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1476

On Tue, May 28, 2024 at 08:04:52PM +0300, Marius Vlad wrote:
> On Tue, May 28, 2024 at 03:53:23PM +, Hoosier, Matt wrote:
> > Hi Marius,
> Hi,
> > 
> > Okay, I guess that answers the bit about needing to screen-scrape to get 
> > content into Pipewire now.
> > 
> > But I'm still a little unclear about a couple things, if I were to try to 
> > build on this PW backend as a starting point:
> > 
> > First, it looks to me like when you use the PW backend to Weston, that
> > becomes your display. That is, rendering directly targets it. I was
> > hoping for a way to get it to broadcast the very same framebuffer(s)
> > that are getting scanned out for the current frame by the DRM
> > backend.
> With https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341
> the PipeWire output can mirror out the native DRM one. It aims at having
> a way to configure VNC, RDP and PipeWire to screen-share the output. 
> > 
> > Second, I'm don't see the path to getting this to leverage the
> > DRM_MODE_CONNECTOR_WRITEBACK hardware (like the weston_screen_recorder
> > does).  I think that any layering would be forced to
> > be offloaded to the GPU ahead of time. Maybe I missed some implication
> > of what you were pointing out here?
> No sorry, I haven't really implied that, just pointed that out there's
> some work for PipeWire gaining dmabuf. 
> 
> Screen-sharing an output is done
> with multiple backends, and configuring Weston front-end is it with 
> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341.
> 
> > 
> > > -Original Message-
> > > From: Marius Vlad 
> > > Sent: Saturday, May 25, 2024 6:12 AM
> > > To: Hoosier, Matt 
> > > Cc: wayland-devel@lists.freedesktop.org
> > > Subject: Re: Full-motion zero-copy screen capture in Weston
> > > 
> > > On Fri, May 24, 2024 at 09:43:58PM +, Hoosier, Matt wrote:
> > > > Hi,
> > > >
> > > > I'm interested in finding or contributing some mechanism to get sort of 
> > > > the
> > > same effect as a cross between:
> > > >
> > > >
> > > >   *
> > > > weston_output_capture's support for using the
> > > > DRM_MODE_CONNECTOR_WRITEBACK connectors, and
> > > >
> > > >   *
> > > > the streamed orientation of weston_screen_recorder, and
> > > >
> > > >   *
> > > > no forced reliance on the GPU to pre-blend the 2D scene – whatever
> > > > plane blending would otherwise have occurred must still occur when the
> > > > screen recording mechanism is active
> > > >
> > > > The desktop environments' compositors implement the XDG screencast
> > > portal. If I read things correctly, that one deposits the stream of 
> > > dmabuf frame
> > > fds into the Pipewire stream indicated by the user invoking the D-Bus
> > > Screencast API.
> > > >
> > > > That doesn't really seem like a starter for doing this in Weston.
> > > > There was conversation back in 2019 about trying to add zero-copy
> > > > dmabuf support in Weston's own Pipewire integration, but I think that
> > > > didn't happen?
> > > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1366
> > > >
> > > > Alternately, I see that the remoting plugin on today's main branch 
> > > > supports
> > > GStreamer dmabuf allocators. Does this mean that I could build something
> > > using a virtual weston_output in the drm-backend?
> > > >
> > > > Cheers,
> > > > Matt




signature.asc
Description: PGP signature

Re: Full-motion zero-copy screen capture in Weston

[Marius Vlad]

On Tue, May 28, 2024 at 03:53:23PM +, Hoosier, Matt wrote:
> Hi Marius,
Hi,
> 
> Okay, I guess that answers the bit about needing to screen-scrape to get 
> content into Pipewire now.
> 
> But I'm still a little unclear about a couple things, if I were to try to 
> build on this PW backend as a starting point:
> 
> First, it looks to me like when you use the PW backend to Weston, that
> becomes your display. That is, rendering directly targets it. I was
> hoping for a way to get it to broadcast the very same framebuffer(s)
> that are getting scanned out for the current frame by the DRM
> backend.
With https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341
the PipeWire output can mirror out the native DRM one. It aims at having
a way to configure VNC, RDP and PipeWire to screen-share the output. 
> 
> Second, I'm don't see the path to getting this to leverage the
> DRM_MODE_CONNECTOR_WRITEBACK hardware (like the weston_screen_recorder
> does).  I think that any layering would be forced to
> be offloaded to the GPU ahead of time. Maybe I missed some implication
> of what you were pointing out here?
No sorry, I haven't really implied that, just pointed that out there's
some work for PipeWire gaining dmabuf. 

Screen-sharing an output is done
with multiple backends, and configuring Weston front-end is it with 
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/341.

> 
> > -Original Message-
> > From: Marius Vlad 
> > Sent: Saturday, May 25, 2024 6:12 AM
> > To: Hoosier, Matt 
> > Cc: wayland-devel@lists.freedesktop.org
> > Subject: Re: Full-motion zero-copy screen capture in Weston
> > 
> > On Fri, May 24, 2024 at 09:43:58PM +, Hoosier, Matt wrote:
> > > Hi,
> > >
> > > I'm interested in finding or contributing some mechanism to get sort of 
> > > the
> > same effect as a cross between:
> > >
> > >
> > >   *
> > > weston_output_capture's support for using the
> > > DRM_MODE_CONNECTOR_WRITEBACK connectors, and
> > >
> > >   *
> > > the streamed orientation of weston_screen_recorder, and
> > >
> > >   *
> > > no forced reliance on the GPU to pre-blend the 2D scene – whatever
> > > plane blending would otherwise have occurred must still occur when the
> > > screen recording mechanism is active
> > >
> > > The desktop environments' compositors implement the XDG screencast
> > portal. If I read things correctly, that one deposits the stream of dmabuf 
> > frame
> > fds into the Pipewire stream indicated by the user invoking the D-Bus
> > Screencast API.
> > >
> > > That doesn't really seem like a starter for doing this in Weston.
> > > There was conversation back in 2019 about trying to add zero-copy
> > > dmabuf support in Weston's own Pipewire integration, but I think that
> > > didn't happen?
> > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1366
> > >
> > > Alternately, I see that the remoting plugin on today's main branch 
> > > supports
> > GStreamer dmabuf allocators. Does this mean that I could build something
> > using a virtual weston_output in the drm-backend?
> > >
> > > Cheers,
> > > Matt


signature.asc
Description: PGP signature

Re: Full-motion zero-copy screen capture in Weston

[Marius Vlad]

On Fri, May 24, 2024 at 09:43:58PM +, Hoosier, Matt wrote:
> Hi,
> 
> I'm interested in finding or contributing some mechanism to get sort of the 
> same effect as a cross between:
> 
> 
>   *
> weston_output_capture's support for using the DRM_MODE_CONNECTOR_WRITEBACK 
> connectors, and
> 
>   *
> the streamed orientation of weston_screen_recorder, and
> 
>   *
> no forced reliance on the GPU to pre-blend the 2D scene – whatever plane 
> blending would otherwise have occurred must still occur when the screen 
> recording mechanism is active
> 
> The desktop environments' compositors implement the XDG screencast portal. If 
> I read things correctly, that one deposits the stream of dmabuf frame fds 
> into the Pipewire stream indicated by the user invoking the D-Bus Screencast 
> API.
> 
> That doesn't really seem like a starter for doing this in Weston.
> There was conversation back in 2019 about trying to add zero-copy
> dmabuf support in Weston's own Pipewire integration, but I think that
> didn't happen?
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1366
> 
> Alternately, I see that the remoting plugin on today's main branch supports 
> GStreamer dmabuf allocators. Does this mean that I could build something 
> using a virtual weston_output in the drm-backend?
> 
> Cheers,
> Matt


signature.asc
Description: PGP signature

Re: Weston mirror/clone to 2 different displays

[Marius Vlad]

On Mon, Apr 29, 2024 at 08:55:31PM +, Dawn HOWE wrote:
> Hello,
Hi,
> 
> I posted a question last year about mirroring/cloning to LVDS/hdmi on
> an imx8, which is not supported by the display driver. This thread
> suggests that a solution for this was being worked last June, but I
> have not seen follow up on the topic since then.  Is there any change
> in the status?
Yes, we landed that in Weston 13, but configuring was left out
for the next version. That work is currently WIP at 
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1476
> 
> thanks,
> Dawn
> 
> 
> 
> 
> From: Daniel Stone 
> Sent: Friday, June 23, 2023 10:04 AM
> To: Dawn HOWE 
> Cc: wayland-devel@lists.freedesktop.org 
> Subject: Re: Weston mirror/clone to 2 different displays
> 
> Hi Dawn,
> 
> On Thu, 22 Jun 2023 at 18:09, Dawn HOWE 
> mailto:dawn.h...@alten.com>> wrote:
> 
> I am developing an (embedded) medical device which is required to have a 
> touchscreen display and also mirror the output to a monitor connected via 
> HDMI. The device is using Wayland/Weston on TorizonCore (based on a yocto 
> kirkstone). I am able to get the display extended from HDMI to LVDS, but not 
> have the output mirrored to both displays. I posted a query on the Toradex 
> community, and received a response that Weston may not be capable of doing 
> this. 
> (https://community.toradex.com/t/apalis-imx8-hdmi-and-lvds-display-not-mirroring-cloning/19869).
> 
> 
> 
> I have searched and found some old posts from several years ago indicating 
> that it was not supported, but may be with a patch. I understand that 
> “same-as” configuration in weston.ini does not work for my scenario.
> 
> 
> 
> What is the current state of cloning/mirroring to two different outputs, but 
> on the same card. E.g (card1-HDMI-A-1 and card1-LVDS-1):
> 
> 
> ls /sys/class/drm
> 
> card0  card1  card1-HDMI-A-1  card1-LVDS-1  renderD128  
> renderD129  version
> 
> Weston can currently mirror it if the display driver directly supports it. 
> You can use the same-as configuration option (see man weston-drm) to enable 
> this. If your display driver doesn't support this in the kernel, then Weston 
> won't do it for now, but we are actively working on this and expect to have a 
> branch capable of this within the next couple of weeks or so.
> 
> Cheers,
> Daniel
> The information contained in this e-mail and any attachments are intended 
> solely for the addressees. If you have received this email in error, please 
> contact the sender and delete the email from your system.


signature.asc
Description: PGP signature

Re: [ANNOUNCE] Weston 13.0.1

[Marius Vlad]

Hi all,

Someone pointed out that the tag was wrong, pointing apparently to
main branch. Had to delete the tag and re-create it. Should now point
correctly. All links are the same, with the same files.

Thanks for heads-up Dylan!

On Tue, Apr 23, 2024 at 06:55:45PM +0300, Marius Vlad wrote:
> Hi all,
> 
> Weston 13.0.1, a bug fix release for 13.0.0 has been released.
> 
> Full changelog below:
> 
> Arnaud Vrac (3):
>   desktop-shell: clamp view alpha correctly
>   desktop-shell: set proper curtain size when no output is created yet
>   clients/desktop-shell: fix crash on init when panel is disabled
> 
> Derek Foreman (3):
>   gl-renderer: apply output transform before readback in repaint
>   libweston: Clip damage to paint node visible region
>   libweston/backends: Move damage flush into backends
> 
> Jeffy Chen (2):
>   renderer-gl: Fix wrong stride error when reading pixels
>   desktop-shell: Avoid using maximized size in fullscreen state
> 
> Marius Vlad (3):
>   backend-pipewire: Move region initialization at the start
>   libweston: Add paint node destruction into weston_layer_entry_remove()
>   build: bump to version 13.0.1 for the point release
> 
> Michael Olbrich (1):
>   ivi-shell: clear seat focus if necessary when a surface is destroyed
> 
> Philipp Zabel (1):
>   libweston-desktop: Work around crash when opening popup menu
> 
> Ray Smith (1):
>   backend-drm: fix confused fallback format handling
> 
> Robert Mader (2):
>   backend-drm: Don't force non-opaque overlays to primary plane
>   backend-drm: Sort planes by faked zpos
> 
> Wujian Sun (1):
>   libweston-desktop: Fix weston crash when lost the shsurf
> 
> git tag: 13.0.1
> 
> https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz
> SHA256: ea1566ab4f5ffce7e9fd4f7a1fca5b30caae4d50023bf459213994094e02b29a  
> weston-13.0.1.tar.xz
> SHA512: 
> 4a0fd0b1aec823219421d701030bc534576be64b71ede70c7d33f131e9e64c0e0dc209e62f75cecb9368df7604c1d5b2321932eccc818b529d246ec2e3114122
>   weston-13.0.1.tar.xz
> PGP:
> https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz.sig
> 




signature.asc
Description: PGP signature

[ANNOUNCE] Weston 13.0.1

[Marius Vlad]

Hi all,

Weston 13.0.1, a bug fix release for 13.0.0 has been released.

Full changelog below:

Arnaud Vrac (3):
  desktop-shell: clamp view alpha correctly
  desktop-shell: set proper curtain size when no output is created yet
  clients/desktop-shell: fix crash on init when panel is disabled

Derek Foreman (3):
  gl-renderer: apply output transform before readback in repaint
  libweston: Clip damage to paint node visible region
  libweston/backends: Move damage flush into backends

Jeffy Chen (2):
  renderer-gl: Fix wrong stride error when reading pixels
  desktop-shell: Avoid using maximized size in fullscreen state

Marius Vlad (3):
  backend-pipewire: Move region initialization at the start
  libweston: Add paint node destruction into weston_layer_entry_remove()
  build: bump to version 13.0.1 for the point release

Michael Olbrich (1):
  ivi-shell: clear seat focus if necessary when a surface is destroyed

Philipp Zabel (1):
  libweston-desktop: Work around crash when opening popup menu

Ray Smith (1):
  backend-drm: fix confused fallback format handling

Robert Mader (2):
  backend-drm: Don't force non-opaque overlays to primary plane
  backend-drm: Sort planes by faked zpos

Wujian Sun (1):
  libweston-desktop: Fix weston crash when lost the shsurf

git tag: 13.0.1

https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz
SHA256: ea1566ab4f5ffce7e9fd4f7a1fca5b30caae4d50023bf459213994094e02b29a  
weston-13.0.1.tar.xz
SHA512: 
4a0fd0b1aec823219421d701030bc534576be64b71ede70c7d33f131e9e64c0e0dc209e62f75cecb9368df7604c1d5b2321932eccc818b529d246ec2e3114122
  weston-13.0.1.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.1/downloads/weston-13.0.1.tar.xz.sig



signature.asc
Description: PGP signature

[ANNOUNCE] Weston 12.0.4

[Marius Vlad]

Hi all,

Weston 12.0.4, a bug fix release for 12.0.0 has been released.

Full changelog below:

Arnaud Vrac (2):
  desktop-shell: clamp view alpha correctly
  clients/desktop-shell: fix crash on init when panel is disabled

Marius Vlad (1):
  build: bump to version 12.0.4 for the point release

Michael Olbrich (1):
  ivi-shell: clear seat focus if necessary when a surface is destroyed

Philipp Zabel (1):
  libweston-desktop: Work around crash when opening popup menu

Robert Mader (2):
  backend-drm: Don't force non-opaque overlays to primary plane
  backend-drm: Sort planes by faked zpos

Tomohito Esaki (4):
  ivi-shell: Properly handle seat hotplugging
  ivi-shell: activate desktop surface
  hmi-controller: activate and deactivate sruface
  ivi-shell-user-interface: change timing to create the launcher surface

Wujian Sun (1):
  libweston-desktop: Fix weston crash when lost the shsurf

git tag: 12.0.4

https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.4/downloads/weston-12.0.4.tar.xz
SHA256: efdb21859b38f8cbc2b4b39ad65cc1ea3ed1adab23ac28bf501a8a9f80a31727  
weston-12.0.4.tar.xz
SHA512: 
c988256b73ea72f06d8ec4faaac2f4a2c52b250b573d3c9906cd00dcba017ad2202875ff04d012b194044715fb5e586331238c54daa508b814c7ab22f3d40006
  weston-12.0.4.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.4/downloads/weston-12.0.4.tar.xz.sig



signature.asc
Description: PGP signature

[ANNOUNCE] Weston bug-fix release schedule -- 13.0.1 and 12.0.4

[Marius Vlad]

Hi all,

I've been postponing these for a while now, and given that Weston 14 is
still in development with some in-flight changes, think it would good to
have at least an intermediary, bug-fix release, for Weston 13,
respectively Weston 12.

Next week, 23 of April, 2024, I'd like to cut both trees and do a
release.  In Gitlab there's 'Backport to Weston 12/13' tag which can be
used if you would like to get some bug-fixes in until then, or just
shout/drop a mail, so I can pick them up.

Also, the MRs to pick up the fixes are opened as well: 

Weston 12 - https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1497
Weston 13 - https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1494

Thanks!


signature.asc
Description: PGP signature

Re: Issue with starting Weston service

[Marius Vlad]

On Sat, Mar 30, 2024 at 09:16:57AM +0530, Akshaya Maran wrote:
> Hi Marius,
Hi,
> 
> pvr kernel module was not loaded properly . After loading the module , I
> end up with below issue ,
> 
> *weston.service - Weston, a Wayland compositor, as a system service*
> *Loaded: loaded (/etc/systemd/system/weston.service; disabled; preset:
> enabled)*
> *Active: failed (Result: exit-code)*
> *  Docs: man:weston(1)*
> *man:weston.ini(5)*
> *http://wayland.freedesktop.org/ <http://wayland.freedesktop.org/>*
> *Process: 252 ExecStart=/usr/bin/weston --modules=systemd-notify.so
> (code=exited, status=224/PAM)*
> *  Main PID: 252 (code=exited, status=224/PAM)*
> *   CPU: 24ms*
> 
> 
> *systemd[1]: Starting weston.service...*
> *(weston)[252]: PAM failed: Authentication service cannot retrieve
> authentication info*
This seems to indicate further issues with your system's
setup/installation regarding PAM (man 3 pam). 
This is unrelated to Weston.
> *(weston)[252]: weston.service: Failed to set up PAM session: Operation not
> permitted*
> *(weston)[252]: weston.service: Failed at step PAM spawning
> /usr/bin/weston: Operation not permitted*
> *systemd[1]: weston.service: Main process exited, code=exited,
> status=224/PAM*
> *systemd[1]: weston.service: Failed with result 'exit-code'.*
> *systemd[1]: Failed to start weston.service.*
> 
> 
> Can you help me with this?
> 
> Thanks,
> Akshaya.M
> 
> On Fri, Mar 29, 2024 at 2:29 PM Marius Vlad 
> wrote:
> 
> > On Fri, Mar 29, 2024 at 12:28:36AM +0530, Akshaya Maran wrote:
> > > Hi,
> > Hi,
> > >
> > > I am facing an issue while trying to start the weston service .
> > > Below is the error message :
> > >
> > > *weston.service - Weston, a Wayland compositor, as a system service*
> > >
> > > * Loaded: loaded (/lib/systemd/system/weston.service; disabled;
> > preset:
> > > enabled)*
> > >
> > > * Active: failed (Result: exit-code)*
> > >
> > > *TriggeredBy: �● weston.socket*
> > >
> > > *   Docs: man:weston(1)*
> > >
> > > * man:weston.ini(5)*
> > >
> > > * http://wayland.freedesktop.org/
> > > <http://wayland.freedesktop.org/>*
> > >
> > > *Process: 167 ExecStart=/usr/bin/weston
> > > --log=${XDG_RUNTIME_DIR}/weston.log --modules=systemd-notify.so
> > > (code=exited, status=1/FAILURE)*
> > >
> > > *   Main PID: 167 (code=exited, status=1/FAILURE)*
> > >
> > > *CPU: 28ms*
> > >
> > >
> > > * weston[167]: failed to load swrast driver*
> > >
> > > * weston[167]: Internal warning: debug scope 'drm-backend' has not been
> > > destroyed.*
> > >
> > > * weston[167]: PVR:(Error): OpenServices: PVRDRMOpenRender failed [0, ]*
> > These issues are related to the graphics driver/display driver and not
> > Weston.
> > Either your installation is broken, incomplete, it's missing something
> > else to run
> > (kernel driver loaded), it can't run on your system, or something else is
> > already
> > using the same resource (DRM master) on system. Suggest looking for
> > 'PVRDRMOpenRender' as that might further assistance to get the graphics
> > driver working.
> > >
> > > * weston[167]: PVR:(Error): PVRSRVConnect: Unable to open connection.
> > [0, ]*
> > >
> > > * weston[167]: PVR:(Error): Couldn't connect to services [0, ]*
> > >
> > > * weston[167]: PVR:(Error): PVRDRIEGLGlobalDataInit: PVR Services
> > > initialisation failed [0, ]*
> > >
> > > * weston[167]: PVR:(Error): PVRDRICreateScreenImpl: Couldn't create EGL
> > > global data [0, ]*
> > >
> > > * systemd[1]: weston.service: Main process exited, code=exited,
> > > status=1/FAILURE*
> > >
> > > * systemd[1]: weston.service: Failed with result 'exit-code'.*
> > >
> > > * systemd[1]: Failed to start weston.service.*
> > >
> > > Can you please help me to understand and fix this error ?
> > >
> > > Thanks,
> > > Akshaya.M
> >


signature.asc
Description: PGP signature

Re: Qustion: Support for Splitting Application Output Across Multiple Displays in Weston

[Marius Vlad]

On Fri, Mar 29, 2024 at 06:46:04PM +0900, Yosuke Nakayama wrote:
> Thanks for the quick response.
> 
> > With a (new) shell, or maybe with additions to desktop-shell, it would
> allow the following to create a virtual output:
> Does this mean that the existing shells (xdg-shell, kiosk-shell, ivi-shell,
> etc.) cannot achieve the functionality?
No, not in the sanse I've described earlier (using the
maximized,fullscreen requests).

With desktop-shell, you can create a region that spans all the
outputs, but not with kiosk-shell. I don't know about ivi-shell, but
with ivi-shell you can have other controllers which can problably achieve 
that, but similarly to the new shell, you might have to write it. Might want
to take a look at the wayland-ivi-extension see if it that has something
like that.
> 
> On Fri, Mar 29, 2024 at 5:45 PM Marius Vlad 
> wrote:
> 
> > On Fri, Mar 29, 2024 at 10:20:50AM +0900, Yosuke Nakayama wrote:
> > > Dear Wayland-devel Community,
> > Hi,
> > >
> > > I am currently exploring the capabilities of Weston, the reference
> > > compositor for Wayland, specifically in the context of an application use
> > > case that I am working on. My goal is to achieve a functionality where
> > the
> > > graphical output of a single application can be divided and displayed
> > > simultaneously across two separate displays. This functionality would
> > > enable part of the application window to be shown on one display and the
> > > rest on another, effectively spanning the application window across
> > > multiple screens.
> > >
> > > From my understanding and current experimentation with Weston, this
> > > particular use case does not seem to be directly supported, but I'm not
> > > sure. Does functionality exist at this time to achieve such a use case?
> > In desktop-shell, maximized and fullscreen xdg-shell calls for a
> > particular will *not* span across multiple outputs, nor there's a way to
> > define a virtual output that will add up multiple physical outputs into
> > a virtual one. For kiosk-shell, windows will be fullscreen'ed to a
> > particular output. That doesn't mean this can't be done. With a (new)
> > shell, or maybe with additions to desktop-shell, it would allow the
> > following to create a virtual output:
> >
> > [virtual-output]
> > output=eDP-1,HDMI-A-1
> > name=MyVirtualOutput-1
> >
> > Then, the compositor will advertise this output as well such that the
> > client can issue a maximized, fullscreen request and have client spanned
> > across those outputs.
> >
> > >
> > > Thank you for your time and assistance!
> > >
> > > Best regards,
> >


signature.asc
Description: PGP signature

Re: Issue with starting Weston service

[Marius Vlad]

On Fri, Mar 29, 2024 at 12:28:36AM +0530, Akshaya Maran wrote:
> Hi,
Hi,
> 
> I am facing an issue while trying to start the weston service .
> Below is the error message :
> 
> *weston.service - Weston, a Wayland compositor, as a system service*
> 
> * Loaded: loaded (/lib/systemd/system/weston.service; disabled; preset:
> enabled)*
> 
> * Active: failed (Result: exit-code)*
> 
> *TriggeredBy: �● weston.socket*
> 
> *   Docs: man:weston(1)*
> 
> * man:weston.ini(5)*
> 
> * http://wayland.freedesktop.org/
> *
> 
> *Process: 167 ExecStart=/usr/bin/weston
> --log=${XDG_RUNTIME_DIR}/weston.log --modules=systemd-notify.so
> (code=exited, status=1/FAILURE)*
> 
> *   Main PID: 167 (code=exited, status=1/FAILURE)*
> 
> *CPU: 28ms*
> 
> 
> * weston[167]: failed to load swrast driver*
> 
> * weston[167]: Internal warning: debug scope 'drm-backend' has not been
> destroyed.*
> 
> * weston[167]: PVR:(Error): OpenServices: PVRDRMOpenRender failed [0, ]*
These issues are related to the graphics driver/display driver and not Weston. 
Either your installation is broken, incomplete, it's missing something else to 
run 
(kernel driver loaded), it can't run on your system, or something else is 
already 
using the same resource (DRM master) on system. Suggest looking for 
'PVRDRMOpenRender' as that might further assistance to get the graphics 
driver working.
> 
> * weston[167]: PVR:(Error): PVRSRVConnect: Unable to open connection. [0, ]*
> 
> * weston[167]: PVR:(Error): Couldn't connect to services [0, ]*
> 
> * weston[167]: PVR:(Error): PVRDRIEGLGlobalDataInit: PVR Services
> initialisation failed [0, ]*
> 
> * weston[167]: PVR:(Error): PVRDRICreateScreenImpl: Couldn't create EGL
> global data [0, ]*
> 
> * systemd[1]: weston.service: Main process exited, code=exited,
> status=1/FAILURE*
> 
> * systemd[1]: weston.service: Failed with result 'exit-code'.*
> 
> * systemd[1]: Failed to start weston.service.*
> 
> Can you please help me to understand and fix this error ?
> 
> Thanks,
> Akshaya.M


signature.asc
Description: PGP signature

Re: Qustion: Support for Splitting Application Output Across Multiple Displays in Weston

[Marius Vlad]

On Fri, Mar 29, 2024 at 10:20:50AM +0900, Yosuke Nakayama wrote:
> Dear Wayland-devel Community,
Hi,
> 
> I am currently exploring the capabilities of Weston, the reference
> compositor for Wayland, specifically in the context of an application use
> case that I am working on. My goal is to achieve a functionality where the
> graphical output of a single application can be divided and displayed
> simultaneously across two separate displays. This functionality would
> enable part of the application window to be shown on one display and the
> rest on another, effectively spanning the application window across
> multiple screens.
> 
> From my understanding and current experimentation with Weston, this
> particular use case does not seem to be directly supported, but I'm not
> sure. Does functionality exist at this time to achieve such a use case?
In desktop-shell, maximized and fullscreen xdg-shell calls for a
particular will *not* span across multiple outputs, nor there's a way to
define a virtual output that will add up multiple physical outputs into
a virtual one. For kiosk-shell, windows will be fullscreen'ed to a
particular output. That doesn't mean this can't be done. With a (new)
shell, or maybe with additions to desktop-shell, it would allow the
following to create a virtual output:

[virtual-output]
output=eDP-1,HDMI-A-1
name=MyVirtualOutput-1

Then, the compositor will advertise this output as well such that the
client can issue a maximized, fullscreen request and have client spanned
across those outputs.

> 
> Thank you for your time and assistance!
> 
> Best regards,


signature.asc
Description: PGP signature

Re: identifying active application/window under wayland

[Marius Vlad]

On Fri, Mar 15, 2024 at 05:07:24AM +, Dan Kortschak wrote:
> Hello,
Hi,
> 
> Apologies if this is not the correct forum for this. If this is the
> case, please direct me to a more appropriate place.
> 
> I have searched the archive and cannot find any topic that appears to
> cover this.
> 
> I am the author of a program that in part needs to be able to obtain
> the identity of the active application and window (including its title)
If the program is a client you won't be find this information, as that's
inherent part of the Wayland architecture (avoid one client 
snooping on another's client data).  The program needs to be part of 
the compositor to be able to have that information. As an example,
with Weston's kiosk shell, you can move/map windows on different outputs
based on their appid: 
https://wayland.pages.freedesktop.org/weston/toc/kiosk-shell.html

Depending on the compositor some of the give you the option to use
plug-ins, or use their libraries to add additional code.
> being used by a user. This is required for context-dependent
> configuration of an external device and also, if configured by the
> user, logging of user activity for time tracking.
> 
> This is readily achievable on the platforms that are currently
> supported (X11 and MacOS), but as far as I can see there does not
> appear to be a unified approach to achieving this under Wayland.
> 
> Is it the case that there is no way to achieve this, or am I just
> missing things that are possible? Is it the case that I may need to
> only cover a subset of DEs and special-case code for each that is
> supported? Are there plans to support this kind of use?
The Wayland architecture incorporates the display server, window manager
and compositor into one, there's no DE similarly to what you have with X.

I'm not aware of a unified way of doing this, but maybe use-reusing 
XDG portals (https://flatpak.github.io/xdg-desktop-portal/docs/) to
achieve the same functionality could be a way of doing that?
> 
> thanks
> Dan
> 


signature.asc
Description: PGP signature

Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston

[Marius Vlad]

Hi,
On Fri, Feb 23, 2024 at 06:14:11AM +, Terry Barnaby wrote:
> I have tried using "weston-debug scene-graph" and I am coming to the
> conclusion that qtwayland 6.5.0 is not really using native Wayland surfaces
> when Qt::WA_NativeWindow is used. From what I can see (and I could easily be
> wrong) the Wayland protocol shows wl_surfaces being created and two
> QWidget's QPlatformNativeInterface nativeResourceForWindow("surface",
> windowHandle()) function does return different wl_surface pointers but even
> at the QWidget level (ignoring gstreamer), a QPainter paint into each of
> these QWidgets actually uses Wayland to draw into just the one top level
> surface and "weston-debug scene-graph" shows only one application
> xdg_toplevel surface and no subsurfaces. I don't know how to determine the
> Wayland surface ID from a wl_surface pointer unfortunately to really check
> this.
I suppose this is to expected given that you don't actually see the video. 
> 
> If my Video QWidget(0) is a top level QWidget, then video is shown and
> "weston-debug scene-graph" shows the application xdg_toplevel and two
> wl_subsurfaces as children.
> 
> Unfortunately I think "weston-debug scene-graph" only shows surfaces that
> are actually "active" so I can't see all of the surfaces that Weston
> actually knows about (is there a method of doing this ?).
Mapped or not, Weston will print out views associated with a surface, if
those views are part of a layer. I don't know what active means in this
case, but you won't be activating wl_surfaces but rather the top-level
xdg-shell window.  Depending on the Weston version it would explicit say
that or not (surface/view being not mapped).
> 
> My feeling is that although Qtwayland is creating native surfaces, it
> actually only uses the one top level one and presumably doesn't "activate"
> (set a role, do something ?) with the other surfaces.
WAYLAND_DEBUG=1 could tell if it creates or not subsurfaces underneath.
> 
> Does anyone know a good list/place where I can ask such detailed qtwayland
> questions ?
https://bugreports.qt.io/projects/QTBUG/issues/QTBUG-122683?filter=allopenissues
> 
> I guess I can work around this by manually creating a Wayland subsurface
> from the Qt top level surface and handing that to waylandsink and then
> manage this subsurface, like hiding, showing and resizing, when the QWidget
> is hidden/shown/resized.
> 
> Or could there be a way of "activating" the child QWidget's Wayland surface
> ?
> 
> 
> 
> On 22/02/2024 18:44, Terry Barnaby wrote:
> > Hi Marius,
> > 
> > Many thanks for the info.
> > 
> > Some notes/questions below:
> > 
> > Terry
> > On 22/02/2024 17:49, Marius Vlad wrote:
> > > Hi,
> > > On Thu, Feb 22, 2024 at 03:21:01PM +, Terry Barnaby wrote:
> > > > Hi,
> > > > 
> > > > We are developing a video processing system that runs on an NXP imx8
> > > > processor using a Yocto embedded Linux system that has Qt6, GStreamer,
> > > > Wayland and Weston.
> > > > 
> > > > We are having a problem displaying the video stream from GStreamer on a
> > > > QWidget. In the past we had this working with Qt5 and older GStreamer,
> > > > Wayland and Weston.
> > > > 
> > > > A simple test program also shows the issue on Fedora37 with QT6 and
> > > > KDE/Plasma/Wayland.
> > > I'm tempted to say if this happens on a desktop with the same Qt
> > > version and
> > > other compositors to be an issue with Qt rather than waylandsink or
> > > the compositor. Note that on NXP they have their own modified Weston
> > > version.
> > 
> > That is my current feeling and is one reason why I tried it on Fedora
> > with whatever Wayland compositor KDE/Plasma is using.
> > 
> > 
> > > > The technique we are using is to get the Wayland surface from
> > > > the QWidget is
> > > > using (It has been configured to use a Qt::WA_NativeWindow) and
> > > > pass this to
> > > > the GStreamer's waylandsink which should then update this
> > > > surface with video
> > > > frames (via hardware). This works when the QWidget is a top
> > > > level Window
> > > > widget (QWidget(0)), but if this QWidget is below others in the
> > > > hierarchy no
> > > > video is seen and the gstreamer pipeline line is stalled.
> > > So the assumption is that aren't there other widgets which obscures this
> > > one, when you move it below others?
> >

Re: Wayland debugging with Qtwayland, gstreamer waylandsink, wayland-lib and Weston

[Marius Vlad]

Hi,
On Thu, Feb 22, 2024 at 03:21:01PM +, Terry Barnaby wrote:
> Hi,
> 
> We are developing a video processing system that runs on an NXP imx8
> processor using a Yocto embedded Linux system that has Qt6, GStreamer,
> Wayland and Weston.
> 
> We are having a problem displaying the video stream from GStreamer on a
> QWidget. In the past we had this working with Qt5 and older GStreamer,
> Wayland and Weston.
> 
> A simple test program also shows the issue on Fedora37 with QT6 and
> KDE/Plasma/Wayland.
I'm tempted to say if this happens on a desktop with the same Qt version and
other compositors to be an issue with Qt rather than waylandsink or
the compositor. Note that on NXP they have their own modified Weston version.
> 
> The technique we are using is to get the Wayland surface from the QWidget is
> using (It has been configured to use a Qt::WA_NativeWindow) and pass this to
> the GStreamer's waylandsink which should then update this surface with video
> frames (via hardware). This works when the QWidget is a top level Window
> widget (QWidget(0)), but if this QWidget is below others in the hierarchy no
> video is seen and the gstreamer pipeline line is stalled.
So the assumption is that aren't there other widgets which obscures this
one, when you move it below others?
> 
> It appears that waylandsink does:
> 
> Creates a surface callback:
> 
>   callback = wl_surface_frame (surface);
> 
>   wl_callback_add_listener (callback, _callback_listener, self);
> 
> Then adds a buffer to a surface:
> 
>     gst_wl_buffer_attach (buffer, priv->video_surface_wrapper);
>     wl_surface_set_buffer_scale (priv->video_surface_wrapper, priv->scale);
>     wl_surface_damage_buffer (priv->video_surface_wrapper, 0, 0, G_MAXINT32,
> G_MAXINT32);
>     wl_surface_commit (priv->video_surface_wrapper);
> 
> But never gets a callback and just sits in a loop awaiting that callback.
> 
> I assume that the surface waylandsink is using, which is created using the
> original QWidget surface (sub-surface ? with window ?) is not "active" for
> some reason.
Possibly when QWidget is below in hierarcy to be a child of of a parent, 
as described in 
https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_parent,
so I assume to have a different surface than the parent one. This would
be easy to determine with WAYLAND_DEBUG. Seems unlikely to a itself a 
sub-surface of a surface.
> 
> 
> I am trying to debug this, but this graphics stack is quite complicated with
> waylandsink, qtwayland, wayland-lib and Weston not to mention the NXP
> hardware levels. My thoughts are that it is something qtwayland is doing
> with the surface stack or thread locking issues (gstreamer uses separate
> threads). I also don't understand Wayland or Weston in detail. So some
> questions:
> 
> 1. Anyone seen something like this ?
Someone else reported something similar but that by causing damage, 
or moving pointer to make the video sub-surface to show up: 
https://gitlab.freedesktop.org/wayland/weston/-/issues/843.
> 
> 2. Anyone any idea one where to look ?
> 
> 3. Given the wl_surface in the Qt app or in waylandsink is there a way I can
> print out its state and the surface hierarchy easily ?
In Weston there's something called scene-graph. You can grab it by
starting Weston with with the --debug argument, then you can print 
with `weston-debug scene-graph` command. A more recent Weston version
would indent sub-surfaces by their (main) surface parent.
> 
> 4. Any idea on any debug methods to use ?
WAYLAND_DEBUG=1 as env variable.
> 
> Cheers
> 
> Terry
> 
> 


signature.asc
Description: PGP signature

Re: Issue with logind-launcher

[Marius Vlad]

Hi,

This is just a speculation, only swiftly looked over your systemd files,
but make sure you have polkit installed on the target.  VT
switching/switching graphics mode requires having it installed.
Believe newer systemd/systemd-login fixed this.

On Wed, Feb 14, 2024 at 02:17:14PM +0530, Akshaya Maran wrote:
> Hello,
> 
> I am trying to run weston11.0.1 using logind launcher but got this error
> " logind: failed to get session seat
> logind: cannot setup systemd-logind helper error:"
> 
> I referred to yocto build . I added
> weston.service,weston.socket,weston-autologin,weston-start and also
> exported variables .
> When I tried to boot , I could see a log for loginctl seat0  but not
> attached to the loginctl session.
> 
> Am I missing any additional packages or services or any files that
> needs to be added  ??
> 
> I am attaching my log and files I used . Can you please help me to
> understand and  solve this issue?
> 
> Thanks
> Akshaya





> [Unit]
> Description=Weston socket
> RequiresMountsFor=/run
> 
> [Socket]
> ListenStream=/run/wayland-0
> SocketMode=0775
> SocketUser=weston
> SocketGroup=wayland
> RemoveOnStop=yes
> 
> [Install]
> WantedBy=sockets.target
> 

> # This is a system unit for launching Weston with auto-login as the
> # user configured here.
> #
> # Weston must be built with systemd support, and your weston.ini must load
> # the plugin systemd-notify.so.
> [Unit]
> Description=Weston, a Wayland compositor, as a system service
> Documentation=man:weston(1) man:weston.ini(5)
> Documentation=http://wayland.freedesktop.org/
> 
> # Make sure we are started after logins are permitted.
> Requires=systemd-user-sessions.service
> After=systemd-user-sessions.service
> 
> # If Plymouth is used, we want to start when it is on its way out.
> After=plymouth-quit-wait.service
> 
> # D-Bus is necessary for contacting logind. Logind is required.
> Wants=dbus.socket
> After=dbus.socket
> 
> # Ensure the socket is present
> Requires=weston.socket
> 
> # Since we are part of the graphical session, make sure we are started before
> # it is complete.
> Before=graphical.target
> 
> # Prevent starting on systems without virtual consoles, Weston requires one
> # for now.
> ConditionPathExists=/dev/tty0
> 
> [Service]
> # Requires systemd-notify.so Weston plugin.
> Type=notify
> EnvironmentFile=/etc/default/weston
> ExecStart=/usr/bin/weston --modules=systemd-notify.so
> 
> # Optional watchdog setup
> #TimeoutStartSec=60
> #WatchdogSec=20
> 
> # The user to run Weston as.
> User=weston
> Group=weston
> 
> # Make sure the working directory is the users home directory
> WorkingDirectory=/home/weston
> 
> # Set up a full user session for the user, required by Weston.
> PAMName=weston-autologin
> 
> # A virtual terminal is needed.
> TTYPath=/dev/tty7
> TTYReset=yes
> TTYVHangup=yes
> TTYVTDisallocate=yes
> 
> # Fail to start if not controlling the tty.
> StandardInput=tty-fail
> StandardOutput=journal
> StandardError=journal
> 
> # Log this user with utmp, letting it show up with commands 'w' and 'who'.
> UtmpIdentifier=tty7
> UtmpMode=user
> 
> [Install]
> # Note: If you only want weston to start on-demand, remove this line with a
> # service drop file
> WantedBy=graphical.target






signature.asc
Description: PGP signature

Re: [PATCH 1/2] drm/tidss: Fix initial plane zpos values

[Marius Vlad]

On Tue, Feb 13, 2024 at 11:57:59AM +0200, Tomi Valkeinen wrote:
> Hi,
Hi,
> 
> On 13/02/2024 11:04, Pekka Paalanen wrote:
> > On Tue, 13 Feb 2024 10:16:36 +0200
> > Tomi Valkeinen  wrote:
> > 
> > > When the driver sets up the zpos property it sets the default zpos value
> > > to the HW id of the plane. That is fine as such, but as on many DSS
> > > versions the driver arranges the DRM planes in a different order than
> > > the HW planes (to keep the non-scalable planes first), this leads to odd
> > > initial zpos values. An example is J721e, where the initial zpos values
> > > for DRM planes are 1, 3, 0, 2.
> > > 
> > > In theory the userspace should configure the zpos values properly when
> > > using multiple planes, and in that sense the initial zpos values
> > > shouldn't matter, but there's really no reason not to fix this and help
> > > the userspace apps which don't handle zpos perfectly. In particular,
> > > Weston seems to have issues dealing with the planes with the current
> > > default zpos values.
> > > 
> > > So let's change the zpos values for the DRM planes to 0, 1, 2, 3.
> > > 
> > > Another option would be to configure the planes marked as primary planes
> > > to zpos 0. On a two display system this would give us plane zpos values
> > > of 0, 0, 1, 2. The end result and behavior would be very similar in this
> > > option, and I'm not aware that this would actually help us in any way.
> > > So, to keep the code simple, I opted for the 0, 1, 2, 3 values.
> > > 
> > > Signed-off-by: Tomi Valkeinen 
> > > Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform 
> > > Display SubSystem")
> > 
> > Hi Tomi,
> > 
> > have you reported this to Weston? What exactly is the problem?
> 
> I haven't. I'm quite unfamiliar with Weston, and Randolph from TI (cc'd) has
> been working on the Weston side of things. I also don't know if there's
> something TI specific here, as the use case is with non-mainline GPU drivers
> and non-mainline Mesa. I should have been a bit clearer in the patch
> description, as I didn't mean that upstream Weston has a bug (maybe it has,
> maybe it has not).
> 
> The issue seen is that when Weston decides to use DRM planes for
> composition, the plane zpositions are not configured correctly (or at all?).
> Afaics, this leads to e.g. weston showing a window with a DRM "overlay"
> plane that is behind the "primary" root plane, so the window is not visible.
> And as Weston thinks that the area supposedly covered by the overlay plane
> does not need to be rendered on the root plane, there are also artifacts on
> that area.
> 
> Also, the Weston I used is a bit older one (10.0.1), as I needed to go back
> in my buildroot versions to get all that non-mainline GPU stuff compiled and
> working. A more recent Weston may behave differently.
Right after Weston 10, we had a few minor changes related to the
zpos-sorting list of planes and how we parse the plan list without having
a temporary zpos ordered list to pick planes from.

And there's another fix for missing out to set out the zpos for scanout
to the minimum available - which seems like a good candidate to explain
what happens in the issue described above. So if trying Weston again,
please try with at least Weston 12, which should have those changes
in.

> 
> > It doesn't seem like a good idea to work around userspace bugs
> > (non-regression, I presume?) with kernel changes.
> 
> Presuming this is not related to any TI specific code, I guess it's a
> regression in the sense that at some point Weston added the support to use
> planes for composition, so previously with only a single plane per display
> there was no issue.
> 
> I agree with you, this patch shouldn't be merged to "fix" issues with tidss
> + Weston. However, the current default zpos values really don't make sense,
> so I think this patch can stand on its own, and should be merged just to
> make the tidss behavior a bit saner.
> 
> But even if this patch merged, the issue with Weston should be looked at
> (*poke* Randolph =).
> 
>  Tomi
> 
> > 
> > 
> > Thanks,
> > pq
> > 
> > > ---
> > >   drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/tidss/tidss_plane.c 
> > > b/drivers/gpu/drm/tidss/tidss_plane.c
> > > index e1c0ef0c3894..68fed531f6a7 100644
> > > --- a/drivers/gpu/drm/tidss/tidss_plane.c
> > > +++ b/drivers/gpu/drm/tidss/tidss_plane.c
> > > @@ -213,7 +213,7 @@ struct tidss_plane *tidss_plane_create(struct 
> > > tidss_device *tidss,
> > >   drm_plane_helper_add(>plane, _plane_helper_funcs);
> > > - drm_plane_create_zpos_property(>plane, hw_plane_id, 0,
> > > + drm_plane_create_zpos_property(>plane, tidss->num_planes, 0,
> > >  num_planes - 1);
> > >   ret = drm_plane_create_color_properties(>plane,
> > > 
> > 
> 


signature.asc
Description: PGP signature

Re: Punch hole logic in gl-renderer in weston

[Marius Vlad]

Hi,

Work towards adding this functionality is discussed at 
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1258

On Tue, Jan 23, 2024 at 01:13:20PM +, Namit Solanki (QUIC) wrote:
> Hi Weston team,
> 
> For the use cases where the GPU composed output (output of
> gl-renderer) is on top (higher z order) of a layer
> (layer has lower z order and layer is composed by Display Processing
> unit), do we have a punch hole logic implemented in
> gl-renderer or Weston so that layer is visible through the punch hole?
> 
> Or Weston always expects that the GPU composed buffer is always at the lowest 
> z order among all layers?
> 
> Example : Suppose, there are four  layers on the display. Layer1 and
> Layer2 are composed by GPU and layer3 and layer4 are composed by
> Display processing unit. The composed output of layer1 and layer2 can
> have higher z order than layer3 and layer4? if yes, how the layer3 and
> layer4 will be visible on screen?
> 
> Please help me in understanding this.
> 
> Thanks
> Namit


signature.asc
Description: PGP signature

Re: Backport to 9.0.0 of: backend-drm: schedule connector disable for detached head

[Marius Vlad]

Hi,

On Mon, Dec 11, 2023 at 11:20:16AM +0100, Martin Petzold wrote:
> Has anyone backported this [1] patch to Weston 9.0.0?
> 
> [1] 
> https://gitlab.freedesktop.org/wayland/weston/-/commit/bcacd9ec5a924317416eabb65a6cd6767d5bfb94
No, it got backported to Weston 11. Think it might be possible to get it
in for Weston 10, but it probably requires quite a of work to get that
in Weston 9, if possible at all. Also, Weston 9 never had any
bug-fixes/point releases, we started doing that from Weston 10.

See https://gitlab.freedesktop.org/wayland/weston/-/releases

> 
> Thanks,
> 
> Martin
> 


signature.asc
Description: PGP signature

[ANNOUNCE] weston 12.0.3

[Marius Vlad]

Hi all,

This is a point/bugfix release for Weston 12.

Full commit history bellow.

Aske Bækdal Møller (1):
  clients: keyboard: fix delete before cursor

Derek Foreman (2):
  toy-toolkit: Fix rotations
  xwm: Fix accidental resizing of windows

Marius Vlad (1):
  build: bump to version 12.0.3 for the point release

git tag: 12.0.3

https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.3/downloads/weston-12.0.3.tar.xz
SHA256: 0fa88359e691ce6de47ee92d7bd0c10ec8c54b064d07b204715fc479eef0db6d  
weston-12.0.3.tar.xz
SHA512: 
689f0c945c5dde212e024e046046eb1dea3f3c40f36f1750901b13854b53f3ae8dd0a355319b12e74822ef96a2dc907d60b2d992e5541ab900f7d74f5f097fa5
  weston-12.0.3.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.3/downloads/weston-12.0.3.tar.xz.sig



signature.asc
Description: PGP signature

[ANNOUNCE] weston 13.0.0

[Marius Vlad]

Hi all,

This is the official release for weston 13.0.0.

Highlights for this release:

- multiple backend support allowing loading multiple backends, vnc, rdp,
  pipewire are secondary backends
- backend-vnc, backend-pipewire and backend-rdp: GL renderer support
- improved fullscreen handling in kiosk-shell which allows xwayland type
  of surfaces be fullscreen
- support for overlapping outputs, which allows placing views on planes when
  they're displayed on multiple outputs


Internal changes:

- desktop-shell now makes use of pointer confinement for fullscreen surfaces
- new test for pointer constrains
- new test for paint-node
- many view/surfaces cleanups, including subsurface view construction,
  weston_view_geometry_dirty_internal() addition
- drop libgbm 21.1.1 from various clients requiring it and from drm-backend;
  libgbm 21.1.1 was already required from Weston 10, but it wasn't explicitly
  requested

API changes:

- weston_view_move_to_layer() wraps movement of a view into a specific layer.
  If the target layer is NULL it would effectively remove the view from the 
scene
  graph. This new helper triggers a view list rebuild, and it performs all the
  necessary steps required to make it so the view is added to the layer,
  respectively removed from the current layer if the target layer is NULL.
  It deals with damaging the old regions of the view and removal from the
  layer, as well as damaging the new region when adding it to a new layer.
  Both desktop-shell and kiosk-shell have been refactored to use this new 
helper.
- weston_coord struct in now use for weston_view_set_position, weston_output
  weston_touch as well as the shells
- added iterator for logging scopes - weston_log_scopes_iterate()

Breaking changes for users:

- launcher: Remove launcher-logind has been removed entirely. This was already
deprecated previously. Users are encourated to use libseat which has
systemd-logind support with its backends.


Marius Vlad (2):
  build: bump to version 13.0.0 for the official release


git tag: 13.0.0

https://gitlab.freedesktop.org/wayland/weston/-/releases/13.0.0/downloads/weston-13.0.0.tar.xz
SHA256: 52ff1d4aa2394a2e416c85a338b627ce97fa71d43eb762fd4aaf145d36fc795a  
weston-13.0.0.tar.xz
SHA512: 
8c656cdf24ec9429c76c64ebd2d58351991f5990a6d4b5900ac913243ad8e2c9c0fb1a748f018d177fbfd7e0a8836d0434d97acec287a8f977d47335ae30eacc
  weston-13.0.0.tar.xz



signature.asc
Description: PGP signature

[ANNOUNCE] weston 12.0.95

[Marius Vlad]

Hi all,

This is the RC3 release for Weston 13.0.0. Full commit history below:

Daniel Stone (2):
  desktop-shell: Map input panel exactly once
  weston-keyboard: Create input_panel_surface earlier

Marius Vlad (2):
  backend-x11: Fix error shutdown path for x11
  build: bump to version 12.0.95 for the RC3 release

git tag: 12.0.95

https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.95/downloads/weston-12.0.95.tar.xz
SHA256: 7c5e761837aed8304ab5c334b8ba6a9e8a27a8ab530126ca98188d7c741657ce  
weston-12.0.95.tar.xz
SHA512: 
cd9dc97348c2f381bc687bbee84fa6b42563abb9d34cdb2c23befde460c25e9c9fe617ca47981f5bb0498d6de073232b5dccb8c18e6047598f4f67b9a8e18b51
  weston-12.0.95.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.95/downloads/weston-12.0.95.tar.xz.sig



signature.asc
Description: PGP signature

[ANNOUNCE] weston 12.0.94

[Marius Vlad]

Hi all,

This is the RC2 release for Weston 13.0.0. Full commit history below:

Aske Bækdal Møller (1):
  clients: keyboard: fix delete before cursor

Derek Foreman (5):
  vnc: Remove scanout plane optimization
  libweston: Don't clip damage to paint node visible region
  libweston: Don't set VISIBILITY_DIRTY on non-primary planes
  vnc: Fix cursor updates
  drm-backend: Fix cursor updates with overlapping heads

Marius Vlad (1):
  build: bump to version 12.0.94 for the RC2 release

git tag: 12.0.94

https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.94/downloads/weston-12.0.94.tar.xz
SHA256: 7c463d7630af5d49bcf92e09e42725eaf22a9a0851e8c90d4d830e9a7c95575b  
weston-12.0.94.tar.xz
SHA512: 
7e5fd718cbee30a466e14be7e35fd9cc1a7eb42c147a77271692fd04af62b6eda7c9c6ac4acfb787e184b0cf34563bad8b98c4159b03b9ccf43ef9958b7d916a
  weston-12.0.94.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.94/downloads/weston-12.0.94.tar.xz.sig



signature.asc
Description: PGP signature

[ANNOUNCE] weston 12.0.93

[Marius Vlad]

Hi all,

This is the RC1 release for Weston 13.0.0. Full commit history below.

Marius Vlad (1):
  build: bump to version 12.0.93 for the RC1 release

git tag: 12.0.93

https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.93/downloads/weston-12.0.93.tar.xz
SHA256: 7a873b477dc4c6a6f46ee1e0b594f8132af530f7ec9b1d02614c5337e8d773c3  
weston-12.0.93.tar.xz
SHA512: 
0fb5f447270605974a1de09ff8014e8647c6f54a7403f2c62644dd93bcc1c593892d0c2cc495a03b5e43dda472c463e141ff8f9535e1d1a92c3285cdd2cbfb93
  weston-12.0.93.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.93/downloads/weston-12.0.93.tar.xz.sig



signature.asc
Description: PGP signature

[ANNOUNCE] weston 12.0.92

[Marius Vlad]

Hi all,

This is the beta release for Weston 13.0.0.

The following changes have been added since the alpha release:

Derek Foreman (1):
  xwm: Fix accidental resizing of windows

Leandro Ribeiro (7):
  color-lcms: unref stock sRGB cprof instead of directly destroying it
  color-noop: make use of xalloc helpers
  color-noop: add stock color profile
  color: add get_stock_sRGB_color_profile() to color manager
  color-lcms: extract color characteristics even when output cprof != NULL
  tests/color-metadata-errors: add mock stock sRGB color profile
  color: do not use NULL as stock sRGB color profile

Marius Vlad (3):
  backend-x11: Move back-end removal to the destroy function
  libweston: Ignore subsurface offsets
  build: bump to version 12.0.92 for the beta release

git tag: 12.0.92

https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.92/downloads/weston-12.0.92.tar.xz
SHA256: ecd0d6bf5a596f1f930eea615aeac9a3ec1c904cf8ac6fb1815bada0ca3cd07a  
weston-12.0.92.tar.xz
SHA512: 
91c8613e980605fadcb7d44a8eca88daa50a8d0bf9421804cab297cc7b2a4a7e76edc844153384f1e5683f5193095892e9e107ed1636391688471ebf7293e7d3
  weston-12.0.92.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.92/downloads/weston-12.0.92.tar.xz.sig



signature.asc
Description: PGP signature

Re: Weston 13 and Weston 12.0.3 release schedule

[Marius Vlad]

Hi all,

Just a heads-up, we're going to postpone our Beta release for the next
week (it should've been today), as to able to fix some issues we've
discovered recently, and also give fdo.org time to "recover". Note that
all the other dates are also shifted with one week.

Thanks!

On Mon, Oct 09, 2023 at 07:36:06PM +0300, Marius Vlad wrote:
> Hi all,
> 
> Here is the release schedule for Weston 13.0, the next major version:
> 
> - Alpha: October 16, in one week
> - Beta: October 23
> - RC1: October 30
> - First possible release: November, 6
> 
> Package maintainers are encouraged to pick up the pre-releases to make
> sure packaging can be tested (and fixed) before the stable release.
> 
> Additionally I'd like to do a Weston 12 bug-fix/point release at the
> same time matching our first possible release date. As usual, we have a
> dedicated label, 'Backport to Weston 12' if there's something you'd like
> to get in for Weston 12, or you can reach out directly.
> 
> Thanks!




signature.asc
Description: PGP signature

[ANNOUNCE] weston 12.0.91

[Marius Vlad]

on to print segment breaks
  linux-dmabuf: replace assert with the new weston-assert

Liu, Kai1 (1):
  xwm: WM_TRANSIENT_FOR should not point to override-redirect window

Loïc Molinari (9):
  gl-renderer: Clip and dispatch vertices in surface coord space
  gl-renderer: Decouple coord space transformation from clipper
  gl-renderer: Derive texcoords from position in the vertex shader
  gl-renderer: Store clipped vertices directly into the vertex buffer
  gl-renderer: Use simple clipper on translated and/or scaled nodes
  gl-renderer: Get rid of axis-aligned bbox check in simple clipper
  gl-renderer: Update HTTP links to vertex clipping resources
  gl-renderer: Move clip_quad() to clipper
  gl-renderer: Make clip_transformed() surf parameter constant

Loïc Yhuel (3):
  libweston: Do not include private headers in shell-utils.h
  gl-renderer: Do not attach the first buffer twice
  gl-renderer: use correct read-back format and support 
WL_SHM_FORMAT_ABGR

Marek Vasut (1):
  backend-drm: document additional-devices parameter

Marius Vlad (25):
  meson.build: reopen main for regular development
  libweston,shared/meson:build Add xkbcommon missing depends
  tests/meson.build: Add missing dependency for xcb-client-helper
  meson.build: Bump libweston major version to 13
  libweston/weston-log: Add a iterator helper for debug scope
  libweston/backend-headless: Remove cleanup_after_cairo()
  gitlab-ci/leak-sanitizer.supp: Suppress entire libfontconfig
  virtme-scripts: Add LSAN_OPTION
  desktop-shell: Do another update transform
  clients/window: Update min_allocation for smaller widths/heights
  desktop-shell: Use a common helper to handle surface resizes
  desktop-shell: Keep track of shsurf being created/removed
  desktop-shell: Handle all other shsurfs
  backend-drm: Make DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP inert
  Revert "clients/window: Update min_allocation for smaller widths/heights"
  backend-drm/meson.build: Require at least mesa 21.1.1
  desktop-shell: Don't reposition windows on every resize
  kiosk-shell: Don't attempt to activate a window
  kiosk-shell: Make sure we have seat focused_surface
  backend-wayland: Don't signal out resize events for activation
  desktop-shell: Branch out the set_maxime/unset_full
  neatvnc.wrap: Update to neatvnc 0.7.0
  compositor/main: Re-work plug-in loading to avoid an invalid color manager
  compositor/main: put remoting/pipewire outputs to the right
  build: bump to version 12.0.91 for the alpha release

Max Ihlenfeldt (2):
  gl-renderer: Always initialize variable
  initialize fourcc with DRM_FORMAT_INVALID

Michael Olbrich (2):
  backend-wayland: fix --fullscreen
  libweston: don't return buffers early with multiple backends

Michael Tretter (9):
  backend-pipewire: remove duplicate empty line
  backend-pipewire: remove unused fields from pipewire_frame_data
  backend-pipewire: move pixman setup into helper functions
  backend-pipewire: move pixman renderbuffer creation to helper
  backend-pipewire: add local variables for spa_buffer and data
  backend-pipewire: make renderer initialization depend on renderer
  backend-drm: print failing output in error message
  backend-drm: add config option require-outputs
  backend-drm: change default for required-outputs to any

Pekka Paalanen (8):
  man: make --wait-for-debugger findable
  doc: set language for Sphinx
  build: use project_source_root()
  build: use full_path()
  backend-drm,pipewire,remoting: do not set monitor serial to "unknown"
  libweston: use xstrdup for head strings
  libweston: set default monitor strings
  shared: add weston-assert

Philipp Zabel (86):
  gl-renderer: split buffer age query out of output_get_damage
  gl-renderer: track damage on dummy renderbuffers
  gl-renderer: remove old damage tracking
  pixman-renderer: Add to_pixman_renderbuffer helper
  backend-wayland: fix memory leak in wayland_shm_buffer_attach
  gl-renderer: add framebuffer object name to gl_renderbuffer
  pixel-formats: Add gl_internalformat
  gl-renderer: add FBO output support
  backend-headless: render to FBO instead of pbuffer
  gl-renderer: remove backend pbuffer support
  gl-renderer: remove pbuffer dummy surface
  renderer-gl: drop unused fields from struct gl_fbo_texture
  gl-renderer: split gl_renderer_do_read_pixels out of 
gl_renderer_do_capture
  gl-renderer: support automatically downloading FBO renderbuffers
  backend-vnc: GL renderer support
  backend-pipewire: add GL renderer support
  backend-wayland: track damage on renderbuffers
  libweston: damage moved outputs
  gl-renderer: fix FBO renderbuffer download extents
  backend-rdp: bring back shadow_surface image

Weston 13 and Weston 12.0.3 release schedule

[Marius Vlad]

Hi all,

Here is the release schedule for Weston 13.0, the next major version:

- Alpha: October 16, in one week
- Beta: October 23
- RC1: October 30
- First possible release: November, 6

Package maintainers are encouraged to pick up the pre-releases to make
sure packaging can be tested (and fixed) before the stable release.

Additionally I'd like to do a Weston 12 bug-fix/point release at the
same time matching our first possible release date. As usual, we have a
dedicated label, 'Backport to Weston 12' if there's something you'd like
to get in for Weston 12, or you can reach out directly.

Thanks!


signature.asc
Description: PGP signature

[ANNOUNCE] weston 10.0.5

[Marius Vlad]

Hi all,

This is a point/bugfix release for Weston 10.0.5.

Full commit history bellow.

Marius Vlad (2):
  backend-drm/meson.build: Require at least mesa 21.1.1
  build: bump to version 10.0.5 for the point release

git tag: 10.0.5

https://gitlab.freedesktop.org/wayland/weston/-/releases/10.0.5/downloads/weston-10.0.5.tar.xz
SHA256: c712f9cebc66b9924550df5ace5d0359e33b5ff961ea6302de789b3fd4cf70df  
weston-10.0.5.tar.xz
SHA512: 
ac797e777423eaef35f4cc5671da0af531de69959e8ba3d41b17d87df05582b103a91f52867036b46e6bcdf472f4f8c9ff4de001049039feccdfdbe8e2299a95
  weston-10.0.5.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/10.0.5/downloads/weston-10.0.5.tar.xz.sig


signature.asc
Description: PGP signature

[ANNOUNCE] weston 11.0.3

[Marius Vlad]

Hi all,

This is a point/bugfix release for Weston 11.0.3.

Full commit history bellow.

Liu, Kai1 (1):
  xwm: WM_TRANSIENT_FOR should not point to override-redirect window

Marius Vlad (2):
  backend-drm/meson.build: Require at least mesa 21.1.1
  build: bump to version 11.0.3 for the point release

Michael Tretter (1):
  backend-drm: schedule connector disable for detached head

git tag: 11.0.3

https://gitlab.freedesktop.org/wayland/weston/-/releases/11.0.3/downloads/weston-11.0.3.tar.xz
SHA256: d5534bc703f2f7a695b9148fbdaa9ebc59b55405d5b03d326b8d3addfacae707  
weston-11.0.3.tar.xz
SHA512: 
755e180e8f7590359501c9e623997518f8c45e5920be7dc10761a4e62df02307ef7f11cb3bed5a17d53aac1d74d5ff5327caaecc1c1f70d81fb7f222c68a04f7
  weston-11.0.3.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/11.0.3/downloads/weston-11.0.3.tar.xz.sig



signature.asc
Description: PGP signature

[ANNOUNCE] weston 12.0.2

[Marius Vlad]

Hi all,

This is a point/bugfix release for Weston 12.0.2.

Full commit history bellow.

Derek Foreman (1):
  data-device: Don't make a weston_coord with no valid space

Leandro Ribeiro (3):
  drm: drop disable_planes being false as a condition to support writeback
  drm: do not pull writeback task if KMS atomic API is not supported
  tests: assert that capture info was received before trying screenshot

Liu, Kai1 (1):
  xwm: WM_TRANSIENT_FOR should not point to override-redirect window

Marius Vlad (3):
  backend-drm: Make DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP inert
  backend-drm/meson.build: Require at least mesa 21.1.1
  build: bump to version 12.0.2 for the point release

Michael Olbrich (1):
  backend-wayland: fix --fullscreen

Pekka Paalanen (1):
  man: make --wait-for-debugger findable

Philipp Zabel (2):
  backend-rdp: extract weston_output_set_single_mode()
  backend-vnc: use weston_output_set_single_mode()

git tag: 12.0.2

https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.2/downloads/weston-12.0.2.tar.xz
SHA256: eb686a7cf00992a23b17f192fca9a887313e92c346ee35d8575196983d656b4a  
weston-12.0.2.tar.xz
SHA512: 
4277cc71a2001768816d6c30df6c01f09ee24efd16651e7048d425afa63c78f92d6def0cca78150965b0f3fa946675b0325881ff9d2878925dedea216a968d59
  weston-12.0.2.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.2/downloads/weston-12.0.2.tar.xz.sig



signature.asc
Description: PGP signature

[ANNOUNCE] Weston bug-fix release schedule -- 12.0.2 and 11.0.3

[Marius Vlad]

Hi all,

I'd like to announce a new point release schedule for Weston 12 and
Weston 11.  There's a pending Weston 13 release as well, but at
this point we still have some in-flight changes to take care of, which
combined with the holidays, would probably make more sense to have the
new release in Autumn. The release schedule for it would also be
announced once some of those changes have made it in the tree.

In the meantime there are a few fixes that have pilled out for Weston 12, 
and for Weston 11, and I'd like to do a point release in the next couple
of weeks, aiming for 2'nd of August.

We've dedicated labels so if there are potential fixes you'd like to get
in, there is  "Backport to weston 12", and "Backport to weston 11". If
you can't use those just ping me and I'll do it for you.

The full list for these are at [1] for Weston 12, respectively at [2], for
Weston 11.

Thanks!

[1] 
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests?scope=all=merged_name[]=Backport%20to%20weston%2012
[2] 
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests?scope=all=merged_name[]=Backport%20to%20weston%2011



signature.asc
Description: PGP signature

Re: Why does Java (XWayland / Weston) resize a Window to 1x1 pixel when HDMI is unplugged (and does not resize back when HDMI is plugged)

[Marius Vlad]

Hi,

Sort of sounds like might have has been fixed with [1].

The change itself was integrated in weston 12, so you'd need to pick
that version to test it out. Debian has only only weston 11 in
experimental so you would need to either grab 12.0 branch from git, or get
it from [2]. In both case you'd have to compile it yourself. If you
manage to test it out and still see the issue, suggest to open a gitlab
ticket.

[1] https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1180
[2] https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.1

On Wed, Jun 07, 2023 at 10:25:28PM +0200, Martin Petzold wrote:
> I guess I have an issue with XWayland (but maybe Weston / Linux). It is very
> specific and I kindly ask for help.
> 
> I have a Java application running on:
> 
> XWayland 2:1.20.11-1+deb11u6, Weston 9.0.0-1, OpenJDK 11.0.18+10-1~deb11u1,
> Debian 11, Kernel 5.10.52
> 
> My JFrame (Window) is set to: 
> GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().setFullScreenWindow(this);
> 
> I can then see my interface on the full screen (in my case it is a TV and I
> have CEC enabled in the Kernel). However, after I UNPLUG HDMI and then PLUG
> HDMI again, my interface is gone (black screen). There is only one small 1x1
> pixel left. It seems the size of the Window is changed by Java / XWayland /
> (Weston). I am sure, that I am not changing it - I checked all resize
> methods on JFrame.
> 
> When I restart my Java application, it is back again - so it is not an issue
> of the OS (Linux) directly and also - most probably - not Weston.
> 
> I also don't have this issue with a pure Wayland application (e.g. Weston
> flower). Using only Wayland (without Java and XWayland) things work.
> 
> When I PLUG the HDMI there is NO java.awt.event.ComponentEvent
> 
> When I UNPLUG HDMI, I get the following java.awt.event.ComponentEvent:
> 
> java.awt.event.ComponentEvent[COMPONENT_RESIZED (0,0 1x1)] on frame0
> java.base/java.lang.Thread.getStackTrace(Thread.java:1602)
> java.desktop/java.awt.AWTEventMulticaster.componentResized(AWTEventMulticaster.java:167)
> java.desktop/java.awt.AWTEventMulticaster.componentResized(AWTEventMulticaster.java:167)
> java.desktop/java.awt.Component.processComponentEvent(Component.java:6461)
> java.desktop/java.awt.Component.processEvent(Component.java:6415)
> java.desktop/java.awt.Container.processEvent(Container.java:2263)
> java.desktop/java.awt.Window.processEvent(Window.java:2049)
> java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5011)
> java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
> java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772)
> java.desktop/java.awt.Component.dispatchEvent(Component.java:4843)
> java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
> java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
> java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
> java.base/java.security.AccessController.doPrivileged(Native Method)
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95)
> java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
> java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
> java.base/java.security.AccessController.doPrivileged(Native Method)
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
> java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
> java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
> java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
> java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
> 
> Unfortunately I also don't know how to manipulate the size after I catched
> this event. I tried to directly set the size back, but this did not work. I
> think it may don't work because at this time HDMI is UNPLUGGED.
> 
> As I don't get any event when the HDMI is PLUGGED again, I also don't know
> when to (try to) set the size back to "normal".
> 
> Thanks,
> 
> Martin


signature.asc
Description: PGP signature

[ANNOUNCE] weston 12.0.1

[Marius Vlad]

Hi all,

This is a point/bug-fix release for weston 12.0.0.

Decided to do another Weston release to punctually address the build
issues uncovered by Jan Engelhardt.

Marius Vlad (3):
  libweston,shared/meson:build Add xkbcommon missing depends
  tests/meson.build: Add missing dependency for xcb-client-helper
  build: bump to version 12.0.1 for the point release

git tag: 12.0.1

https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.1/downloads/weston-12.0.1.tar.xz
SHA256: b18591eab278bc191720f6c09158040b795e7118af1d5ddca6acd9a8e2039535 
 weston-12.0.1.tar.xz
SHA512: 
3dcfa1a2a6b9a605d3ecd597bf7ac0f87b0fd1971845b6e5c44b5e34296943ac146dae6e1cfea9be14ad7a9a8b6d30dc765f9289ef80920d7c516ebba1ba4688 
 weston-12.0.1.tar.xz
PGP: 
https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.1/downloads/weston-12.0.1.tar.xz.sig

Re: [ANNOUNCE] weston 12.0.0

[Marius Vlad]

Hi Jan,

Thanks a lot for the patch, it seems that there are actually two issues here:
one with xkbcommon and one with wayland-client. I'll split these up and
do a point release soon.

On Wed, May 17, 2023 at 11:15:34PM +0200, Jan Engelhardt wrote:
> 
> On Wednesday 2023-05-17 23:01, Jan Engelhardt wrote:
> >On Wednesday 2023-05-17 21:14, Marius Vlad wrote:
> >>This is the official release for weston 12.0.0.
> >
> >Fails to build, it misses properly adding the output from xkbcommon.pc to the
> >compiler command line:[...]
> 
> Patch follows.
> 
> 
> 
> [5s] FAILED: libweston/libgl-borders.a.p/gl-borders.c.o 
> [5s] cc -Ilibweston/libgl-borders.a.p -Ilibweston -I../libweston -I. -I.. 
> -Iinclude -I../include -I/usr/include/wayland -I/usr/include/pixman-1 
> -I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/freetype2 
> -I/usr/include/webp -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall 
> -Winvalid-pch -Wextra -Wpedantic -std=gnu99 -Wmissing-prototypes 
> -Wno-unused-parameter -Wno-shift-negative-value 
> -Wno-missing-field-initializers -Wno-pedantic -Wundef -fvisibility=hidden -O2 
> -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong 
> -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection 
> -Werror=return-type -flto=auto -g -fPIC -MD -MQ 
> libweston/libgl-borders.a.p/gl-borders.c.o -MF 
> libweston/libgl-borders.a.p/gl-borders.c.o.d -o 
> libweston/libgl-borders.a.p/gl-borders.c.o -c ../libweston/gl-borders.c
> [5s] In file included from ../libweston/renderer-gl/gl-renderer.h:32,
> [5s]  from ../libweston/gl-borders.h:28,
> [5s]  from ../libweston/gl-borders.c:31:
> [5s] ../include/libweston/libweston.h:39:10: fatal error: 
> xkbcommon/xkbcommon.h: No such file or directory
> 
> [4s] FAILED: shared/libshared.a.p/config-parser.c.o 
> [4s] cc -Ishared/libshared.a.p -Ishared -I../shared -I. -I.. -Iinclude 
> -I../include -I/usr/include/wayland -I/usr/include/pixman-1 
> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra 
> -Wpedantic -std=gnu99 -Wmissing-prototypes -Wno-unused-parameter 
> -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic 
> -Wundef -fvisibility=hidden -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 
> -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables 
> -fstack-clash-protection -Werror=return-type -flto=auto -g -fPIC -MD -MQ 
> shared/libshared.a.p/config-parser.c.o -MF 
> shared/libshared.a.p/config-parser.c.o.d -o 
> shared/libshared.a.p/config-parser.c.o -c ../shared/config-parser.c
> [4s] In file included from ../shared/config-parser.c:44:
> [4s] ../include/libweston/libweston.h:39:10: fatal error: 
> xkbcommon/xkbcommon.h: No such file or directory
> 
> [6s] FAILED: tests/libtest-xwayland-client.a.p/xcb-client-helper.c.o 
> [6s] cc -Itests/libtest-xwayland-client.a.p -Itests -I../tests -I. -I.. 
> -Iinclude -I../include -Iprotocol -I/usr/include/pixman-1 
> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra 
> -Wpedantic -std=gnu99 -Wmissing-prototypes -Wno-unused-parameter 
> -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic 
> -Wundef -fvisibility=hidden -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 
> -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables 
> -fstack-clash-protection -Werror=return-type -flto=auto -g -fPIC -MD -MQ 
> tests/libtest-xwayland-client.a.p/xcb-client-helper.c.o -MF 
> tests/libtest-xwayland-client.a.p/xcb-client-helper.c.o.d -o 
> tests/libtest-xwayland-client.a.p/xcb-client-helper.c.o -c 
> ../tests/xcb-client-helper.c
> [6s] ../tests/xcb-client-helper.c:39:10: fatal error: wayland-client.h: 
> No such file or directory
> 
> ---
>  libweston/meson.build |1 +
>  shared/meson.build|2 +-
>  tests/meson.build |2 +-
>  3 files changed, 3 insertions(+), 2 deletions(-)
> 
> Index: weston/libweston/meson.build
> ===
> --- weston.orig/libweston/meson.build
> +++ weston/libweston/meson.build
> @@ -255,6 +255,7 @@ lib_gl_borders = static_library(
>   dependencies: [
>   dep_lib_cairo_shared,
>   dep_egl, # for gl-renderer.h
> + dep_xkbcommon,
>   ],
>   build_by_default: false,
>   install: false
> Index: weston/shared/meson.build
> ===
> --- weston.orig/shared/meson.build
> +++ weston/shared/meson.build
> @@ -7,7 +7,7 @@ srcs_libshared = [
>  'process-util

[ANNOUNCE] weston 12.0.0

[Marius Vlad]

ependently using their 
  power state (DPMS on/off)
 
Breaking changes for users:

- libweston-desktop DSO has been incorporated into libweston.  Linking now with
libweston would provide access to the former libweston-desktop library.  Users
of libweston-desktop would need to adjust their headers to
 rather than using .
Otherwise, the API itself remains the same

- ivi-layout: simplify API - all struct ivi_layout_interface function pointers
have their return values removed

Marius Vlad (1):
  build: bump to version 12.0.0 for the official release

git tag: 12.0.0

https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.0/downloads/weston-12.0.0.tar.xz
SHA256: 91853c86472cc1311465d29cda5abbe987aff01af53a4406c4513b7a023aba8b  
weston-12.0.0.tar.xz
SHA512: 
a3079be86e173ea3a216cf9c30738097fcf5e1b7c2de4c413a0fd4eb9f28d97fa4e378359a3f59485d282f9b2d7914584d0497a3436d4c3f22bc9bebf9733157
  weston-12.0.0.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/12.0.0/downloads/weston-12.0.0.tar.xz.sig



signature.asc
Description: PGP signature

[ANNOUNCE] weston 11.0.2

[Marius Vlad]

Hi all,

This is a point/bugfix release for weston 11.0.0.

Full commit history bellow.

Alexandros Frantzis (1):
  xwayland: Handle shell hint for client to choose dimensions

Leandro Ribeiro (1):
  desktop-shell: do not forget to reset pending config size after resizes

Marius Vlad (8):
  remoting-plugin: Release and detach the head
  remoting-plugin: Check virtual outputs/remoting instance
  pipewire: Follow-up with remoting pluging when releasing the head
  pipewire: Fix memleak upon compositor shutdown
  pipewire: Destroy the pipewire outputs at shutdown
  pipewire-plugin: Check virtual outputs/remoting instance
  backend-drm: Do not overwrite plane's index when creating virtual plane
  build: bump to version 11.0.2 for the point release

Michael Olbrich (2):
  libweston: clear parent_view when the parent view is destroyed
  desktop-shell: avoid crashes when a surface disappears during resize

Sergio Gómez (4):
  libweston/input: Remove redundant surface destroy listener in constraints
  libweston: Add view unmap listener to pointer constraints
  libweston: Add assert for valid confine region in 
maybe_warp_confined_pointer()
  libweston/input: Fix assert for valid confine region

git tag: 11.0.2

https://gitlab.freedesktop.org/wayland/weston/-/releases/11.0.2/downloads/weston-11.0.2.tar.xz
SHA256: 7240752cef0b7de622baf8bd5348e63fc6b19f02ef824961b2add177d9652952  
weston-11.0.2.tar.xz
SHA512: 
3b63d1042f64dcb1a5f90f3bf2281dd862b27592f7c15252850746eccff35e930f045ce5c191aaa1423ed6ecb8a56b0336af58d35758c956a84749622c42d6db
  weston-11.0.2.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/11.0.2/downloads/weston-11.0.2.tar.xz.sig



signature.asc
Description: PGP signature

[ANNOUNCE] weston 10.0.4

[Marius Vlad]

Hi all,

This is a point/bugfix release for weston 10.0.0.

Full commit history bellow.

Marius Vlad (1):
  build: bump to version 10.0.4 for the point release

Sergio Gómez (4):
  libweston/input: Remove redundant surface destroy listener in constraints
  libweston: Add view unmap listener to pointer constraints
  libweston: Add assert for valid confine region in 
maybe_warp_confined_pointer()
  libweston/input: Fix assert for valid confine region

git tag: 10.0.4

https://gitlab.freedesktop.org/wayland/weston/-/releases/10.0.4/downloads/weston-10.0.4.tar.xz
SHA256: fc3208b9d228cba734fe8f8cba18b18e48aaede3829030ea62d71f6e3ad8fd97  
weston-10.0.4.tar.xz
SHA512: 
34b10a7e1e4bd9320617a33b52d802b4e6a1be779760fffb3a3c4a63d947e77211652e405badd234f17440a233cefbf78541f85e6d806bb183c94ae52902acc8
  weston-10.0.4.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/10.0.4/downloads/weston-10.0.4.tar.xz.sig



signature.asc
Description: PGP signature

[ANNOUNCE] weston 11.0.93

[Marius Vlad]

Hi all,

This is the RC1 release for Weston 12.0.0. Full commit history below.

Marius Vlad (1):
  build: bump to version 11.0.93 for the RC1 release

Philipp Zabel (1):
  libweston: consolidate 'Using GL/Pixman renderer' log message

git tag: 11.0.93

https://gitlab.freedesktop.org/wayland/weston/-/releases/11.0.93/downloads/weston-11.0.93.tar.xz
SHA256: df2c84abbf7cc448176ac4b7f2556c03d35989930556cb326c5aa44759534336 
 weston-11.0.93.tar.xz
SHA512: 
65ca25cac2ea230d345a9e6489676fde59e620d910f7213858207b00621ae9416f24b5ea50868673d6de438e0a341800a4171c453b093a8f511077991cd80d7a 
 weston-11.0.93.tar.xz
PGP: 
https://gitlab.freedesktop.org/wayland/weston/-/releases/11.0.93/downloads/weston-11.0.93.tar.xz.sig

[ANNOUNCE] weston 11.0.92

[Marius Vlad]

Hi all,

This is the beta release for Weston 12.0.0.

The following changes have been added since the alpha release:

Leandro Ribeiro (3):
  tests/color-icc-output: differentiate test name based on ICC profile type
  tests/color-icc-output: assert that dimension is not zero when creating 
clut
  tests/color-icc-output: add ICC VCGT tests

Marius Vlad (1):
  meson.build: Bump to version 11.0.92 for the beta release

Pekka Paalanen (8):
  build: set project, not global, arguments
  backend-drm: let EDID parser return malloc'd strings
  backend-drm: move struct drm_edid definition
  backend-drm: add drm_head_info_from_edid()
  CI: always use wrap-mode=nofallback
  CI: install libdisplay-info
  backend-drm: use libdisplay-info
  backend-drm: drop HDR without libdisplay-info

Simon Ser (1):
  clients/scaler: check viewporter availability

git tag: 11.0.92

https://gitlab.freedesktop.org/wayland/weston/-/releases/11.0.92/downloads/weston-11.0.92.tar.xz
SHA256: 722db92e81073271fd62dbe21b68f8bdd80c8134768978bc3c86d318d9be7b64  
weston-11.0.92.tar.xz
SHA512: 
acd6d9c9feb51c7a386ea0f62528d3ba28c5cea45e8d17c5ea6dde3a4748ab12526b724a6e227d925f1624f466fd12fe53dc71400c2b45432fb7c9bdfb3bdce0
  weston-11.0.92.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/-/releases/11.0.92/downloads/weston-11.0.92.tar.xz.sig



signature.asc
Description: PGP signature

[ANNOUNCE] weston 11.0.91

[Marius Vlad]

t node transform
  kms: Support bitmasks
  kms: Add plane rotation property
  backend-drm: Set rotation property on planes when possible
  drm-backend: Enable plane rotations
  xwm: Be careful with window size when minimizing
  libweston: Fix broken paint node list walk
  input: Don't assert when sending touch motion
  clipping: Use struct weston_coord in vertex clipping code
  libweston: replace weston_output_transform_coordinate
  tests: Don't send real coordinates with WL_TOUCH_UP events
  backend: Make input notification functions use weston_coord
  input: Convert weston_pointer_motion_event to weston_coord
  input: Convert vec2d to weston_coord
  input: Use weston_coord for weston_pointer_motion_to_rel
  input: Use weston_coord in add_border
  libweston: Pass weston_coords to weston_compositor_pick_view
  input: Convert weston_view_takes_input_at_point to weston_coord
  input: Convert weston_pointer_motion_to_abs() to weston_coord
  input: Use weston_coord for pointer clamping
  input: use weston_coord for weston_pointer_move_to
  input: Use weston_coord for weston_touch functions
  data-device: convert weston_drag focus functions to weston_coord
  libweston: Use weston_coord in struct weston_pointer
  data-device: Make struct weston_drag use weston_coord
  backend-x11: use weston_coord to store previous pointer position
  libweston: Convert struct weston_subsurface to weston_coord
  libweston: Use weston_coord in struct weston_view
  libweston: Use weston_coord in surface committed handler
  desktop-shell: Use weston_coord for saved position
  libweston: Convert weston_output_move to weston_coord
  xwm: Init window link after removing it
  xwm: Add support for xwayland_shell_v1
  compositor: Rename position.set to position.changed

Emmanuel Gil Peyrot (2):
  DRM: Add support for HDMI content type
  libweston: Optimise matrix multiplication

Emre Ucan (2):
  ivi-shell: listen output_created signal
  ivi-shell: listen output_destroyed_signal

Faith Ekstrand (1):
  Add a .mailmap file

Harsha M M (1):
  ivi-shell: Set view mask solely based on source rectangle

Hideyuki Nagase (3):
  rdp: Transform damage regions
  rdp: Pass a monitor configuration to rdp_head_create
  rdp: Add preliminary rdp multihead support

Jonas Ådahl (3):
  compositor: Don't overwrite offset on attach
  shell: Keep window 'activated' state if child has focus
  desktop: Make popup grab follow keyboard focus semantics

Leandro Ribeiro (22):
  libweston/input: update view transforms when pointer is constrained
  libweston/input: update view transforms when handling confined 
pointer motion

  desktop-shell: avoid alternating surface between outputs
  desktop-shell: do not forget to reset pending config size after 
resizes

  Revert "desktop-shell: avoid alternating surface between outputs"
  drm-backend: add supported formats for writeback connectors
  drm-backend: add support to output capture writeback source
  drm-backend: add writeback connector screenshooter to DRM-backend
  drm-backend: address case in which writeback takes longer than 
atomic commit

  drm-backend: move aux function up to remove unnecessary declaration
  tests: add writeback sreenshooter test
  backend-drm: change dmabuf_feedback_maybe_update() return type to 
void
  backend-drm: remove scanout tranche when there are no planes 
available
  backend-drm: add scanout tranche even for views eligible for 
direct scanout

  backend-drm: cosmetic changes to dmabuf_feedback_maybe_update()
  clients/simple-dmabuf-feedback: drop outdated comment
  drm: allow to skip composition if pending capture is writeback
  color-lcms: save ICC profile version string with a single decimal 
value

  color-lcms: add debug scope for color tranformations
  color-lcms: add debug scope for color profiles
  color-lcms: add debug scope for pipeline optimizer
  tests/color-icc-output: make use of color debug scopes

Loïc Molinari (5):
  gl-renderer: Set blend func once per output repaint
  gl-renderer: Enable vertex attrib arrays once per pass
  gl-renderer: Disable vertex attrib arrays in shadow pass
  weston-log-flight-rec: Map ring buffer using memset()
  gl-renderer: Get rid of begin fence sync

Lyude Paul (4):
  clients/window: Add tablet cursor support into libtoytoolkit
  clients: Add support for tablet cursor motion to window frames in 
libtoytoolkit
  clients/desktop-shell: Add tablet support to the top panel of the 
desktop shell

  clients: Add demo application for tablets

Marco Felsch (1):
  ivi-shell: add screenshot capability

Marius Vlad (50):
  libweston/desktop: Migrate libweston-desktop/libweston-desktop.h
  compositor/main: Extract split/retriev

Weston 12.0 release schedule and 11/10 bug fix release

[Marius Vlad]

Hi all,

Here is the release schedule for Weston 12.0, the next major version:

- Alpha: April 26th, in one week and a half
- Beta: May 3rd
- RC1: May 10th
- First possible release: May 17th

Package maintainers are encouraged to pick up the pre-releases to make
sure packaging can be tested (and fixed) before the stable release.

Further more, a point release for Weston 11 (11.0.2) and one for Weston 10 
(10.0.4) is also scheduled to happen at the same time.

If there's anything you'd like to get in for Weston 11.0.2 use the
"Backport to weston 11" label, while for Weston 10, I've created "
"Backport to weston 10". There's just one bug-fix for Weston 10,
while for Weston 11 a few have pilled up.

You can also browse these directly at [1] or at [2].

If there are any objections for these dates please let me know, or if
there's antything you might want to include in the point releases and
for some reason you can't tag/mark them yourself, feel free to reach
out.

Thanks,

[1] - 
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests?scope=all=merged_name[]=Backport%20to%20weston%2011
[2] - 
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests?scope=all=merged_name[]=Backport%20to%20weston%2010




signature.asc
Description: PGP signature

Re: Wayland/weston, Qt and RDP connection...

[Marius Vlad]

On Wed, Jan 18, 2023 at 12:12:43PM +, Matti Ristimäki wrote:
> Hi,
Hi,
> 
> 
> 
> Thanks for the reply!
> 
> 
> 
> Of course in our embedded system the CPX Control Panel(Qt)  works normally 
> via (HDMI) without any problems. And when it is running, it uses 
> WAYLAND_DISPLAY=wayland-0 and DRM back-end.
> 
> 
> 
> 
> 
> Question:
> 
> 
> 
> One shall never start the "second" Weston if screen sharing is desired, only 
> the screen-share plugin in the "first" Weston can do that.
> 
> 
> 
> For some reason, the rdp-backend is not started even if the screen-share.so' 
> module is loaded?
> 
> I’m just missing some RDP related configuration in the weston.ini…?
You need at least weston 10, for that start-on-startup to work.
Otherwise you'll have to perform Mod+Alt+s on the keyboard to start 
screen sharing.
> 
> 
> 
> 
> 
> Here is two test using CPX Control Panel(Qt) and weston-simple-egl.
> 
> 
> 
> ---
> 
> ---
> 
> 
> 
> 
> 
> Testing with CPX Control Panel(Qt)
> 
> 
> 
> ---
> 
> 
> 
> root@sm2s-imx8mp:~# ls -la /run/user/0/
> 
> total 48
> 
> drwx-- 3 root root   140 Jan 18 10:57 .
> 
> drwxr-xr-x 3 root root60 Jan 18 10:09 ..
> 
> srw-rw-rw- 1 root root 0 Jan 18 10:09 bus
> 
> drwxr-xr-x 4 root root   120 Jan 18 10:09 systemd
> 
> srwxr-xr-x 1 root root 0 Jan 18 10:57 wayland-0
> 
> -rw-r- 1 root root 0 Jan 18 10:46 wayland-0.lock
> 
> -rw-r--r-- 1 root root 45744 Jan 18 10:57 weston.log
> 
> 
> 
> ---
> 
> 
> 
> root@sm2s-imx8mp:/opt/cpx# systemctl status cpx
> 
> ● cpx.service - Planmeca Dental Unit CPX Control Panel
> 
>  Loaded: loaded (/lib/systemd/system/cpx.service; enabled; vendor preset: 
> enabled)
> 
>  Active: active (running) since Wed 2023-01-18 12:28:02 CET; 11s ago
> 
>Main PID: 1424 (cpx.sh)
> 
>   Tasks: 13 (limit: 880)
> 
>  Memory: 44.5M
> 
>  CGroup: /system.slice/cpx.service
> 
>  ├─1424 /bin/bash /opt/cpx/cpx.sh
> 
>  └─1428 ./cpx --rotate=0
> 
> 
> 
> 
> 
> ---
> 
> 
> 
> 
> 
> root@sm2s-imx8mp:/opt/cpx# tail -f /run/user/0/weston.log
> 
> [12:27:59.698] Output 'HDMI-A-1' enabled with head(s) HDMI-A-1
> 
> [12:27:59.698] Compositor capabilities:
> 
>arbitrary surface rotation: yes
> 
>screen capture uses y-flip: yes
> 
>presentation clock: CLOCK_MONOTONIC, id 1
> 
>presentation clock resolution: 0.1 s
> 
> [12:27:59.699] Loading module '/usr/lib/weston/kiosk-shell.so'
> 
> [12:27:59.700] Loading module '/usr/lib/weston/screen-share.so'
> 
> [12:27:59.700] Loading module '/usr/lib/weston/systemd-notify.so'
> 
> [12:27:59.700] info: add 1 socket(s) provided by systemd
> 
> 
> 
> 
> 
> ---
> 
> 
> 
> CPX Control Panel starts normally, but the rdp-backend is not started even if 
> the screen-share.so' module is loaded.
> 
> 
> 
> 
> 
> [cid:image001.png@01D92B46.ED2859D0]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ---
> 
> ---
> 
> 
> 
> 
> 
> 
> 
> Testing with weston-simple-egl
> 
> 
> 
> When starting weston-simple-egl, it runs normally as well using drm. (And 
> also screen-share.so is running.)
> 
> 
> 
> ---
> 
> 
> 
> 
> 
> root@sm2s-imx8mp:~# ls -la /run/user/0/
> 
> total 48
> 
> drwx-- 3 root root   140 Jan 18 10:57 .
> 
> drwxr-xr-x 3 root root60 Jan 18 10:09 ..
> 
> srw-rw-rw- 1 root root 0 Jan 18 10:09 bus
> 
> drwxr-xr-x 4 root root   120 Jan 18 10:09 systemd
> 
> srwxr-xr-x 1 root root 0 Jan 18 10:57 wayland-0
> 
> -rw-r- 1 root root 0 Jan 18 10:46 wayland-0.lock
> 
> -rw-r--r-- 1 root root 45744 Jan 18 10:57 weston.log
> 
> 
> 
> 
> 
> ---
> 
> 
> 
> 
> 
> root@sm2s-imx8mp:/opt/cpx# systemctl status cpx
> 
> ● cpx.service - Planmeca Dental Unit CPX Control Panel
> 
>  Loaded: loaded 

Re: Wayland/weston, Qt and RDP connection...

[Marius Vlad]

On Mon, Jan 16, 2023 at 02:25:25PM +, Matti Ristimäki wrote:
> Hi,
Hi,
> 
> 
> 
> Ok, this might be the reason…
> 
> Your Qt app segfaults in the stand-alone RDP Weston instance case. We
> have no idea why that would be, when weston-smoke works. If it is
> because the app requires hardware accelerated OpenGL (or you use a
> proprietary EGL implementation), then it might still
> work with the DRM-backend. This is because the RDP-backend does not
> yet support hardware accelerated OpenGL or Vulkan apps. Normally apps
> will just fall back to Mesa's software renderer, but maybe your app
> needs something extra or maybe you are not using Mesa as your EGL etc.
> 
Right, the proprietary driver can't/won't fallback to a software renderer,
or it doesn't have a pipeline that can do that.

Also, you could probably replicate this without the RDP backend at all,
by just start weston with --use-pixman argument and attempt to start any
client that wants to perform 3D/hardware acceleration and would
probably die out the same.
> 
> 
> 
> 
> Testing weston-simple-egl with RDP and HDMI-display
> 
> 
> 
> 
> 
> "Force driving" weston-simple-egl to RDP-weston session: 
> (WAYLAND_DISPLAY=wayland-1)
> 
> 
> 
> Command:
> 
> 
> 
> WAYLAND_DISPLAY=wayland-1 weston-simple-egl
> 
> has EGL_EXT_buffer_age and EGL_EXT_swap_buffers_with_damage
> 
> Segmentation fault
> 
> 
> 
> Logging:
> 
> 
> 
> root@sm2s-imx8mp:~# journalctl -f
> 
> -- Journal begins at Mon 2023-01-16 09:50:23 CET. --
> 
> Jan 16 11:47:32 sm2s-imx8mp audit[1569]: ANOM_ABEND auid=0 uid=0 gid=0 ses=5 
> pid=1569 comm="weston-simple-e" exe="/usr/bin/weston-simple-egl" sig=11 res=1
> 
> Jan 16 11:47:32 sm2s-imx8mp kernel: audit: type=1701 
> audit(1673866052.888:25): auid=0 uid=0 gid=0 ses=5 pid=1569 
> comm="weston-simple-e" exe="/usr/bin/weston-simple-egl" sig=11 res=1
> 
> 
> 
> Result:
> 
> 
> 
> Doesn't work.
> 
> 
> 
> 
> 
> And similar error appears, when I’m trying to drive “Qt” application on 
> RDP-weston:
> 
> 
> 
> Jan 16 13:51:55 sm2s-imx8mp audit[2027]: ANOM_ABEND auid=0 uid=0 gid=0 ses=5 
> pid=2027 comm="QSGRenderThread" exe="/opt/cpx/cpx" sig=11 res=1
> 
> Jan 16 13:51:55 sm2s-imx8mp kernel: audit: type=1701 
> audit(1673873515.594:33): auid=0 uid=0 gid=0 ses=5 pid=2027 
> comm="QSGRenderThread" exe="/opt/cpx/cpx" sig=11 res=1
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "Force driving" weston-simple-egl to a HDMI display 
> (WAYLAND_DISPLAY=wayland-0)
> 
> 
> 
> Command:
> 
> 
> 
> WAYLAND_DISPLAY=wayland-0 weston-simple-egl
> 
> 
> 
> Logging:
> 
> 
> 
> root@sm2s-imx8mp:/opt/cpx# WAYLAND_DISPLAY=wayland-0 weston-simple-egl
> 
> has EGL_EXT_buffer_age and EGL_EXT_swap_buffers_with_damage
> 
> 304 frames in 5 seconds: 60.79 fps
> 
> 302 frames in 5 seconds: 60.42 fps
> 
> 302 frames in 5 seconds: 60.42 fps
> 
> 302 frames in 5 seconds: 60.42 fps
> 
> 302 frames in 5 seconds: 60.42 fps
> 
> 
> 
> 
> 
> Result:
> 
> 
> 
> Works fine, animation runs smoothly.
> 
> 
> 
> [cid:image001.png@01D929AF.41CA1A80]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> BR,
> 
> 
> 
> -Matti
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -Original Message-
> From: Pekka Paalanen 
> Sent: maanantai 16. tammikuuta 2023 11.40
> To: Matti Ristimäki 
> Cc: Marius Vlad ; 
> wayland-devel@lists.freedesktop.org
> Subject: Re: Wayland/weston, Qt and RDP connection...
> 
> 
> 
> On Sat, 14 Jan 2023 11:58:37 +0200
> 
> Marius Vlad mailto:marius.v...@collabora.com>> 
> wrote:
> 
> 
> 
> > On Fri, Jan 13, 2023 at 08:07:07PM +, Matti Ristimäki wrote:
> 
> > > Hi,
> 
> > Hi,
> 
> > >
> 
> > >
> 
> > >
> 
> > > Thanks for the reply!
> 
> > >
> 
> > >
> 
> > >
> 
> > > Jep, this might be the reason...
> 
> > >
> 
> > > > --modules=systemd-notify.so --modules=screen.share

Re: Wayland/weston, Qt and RDP connection...

[Marius Vlad]

log is in the attachment 
> (wayland-qt-cpx---Segmentation fault---log file.txt)
> 
> .
> 
> .
> 
> .
> 
> 
> 
> qt.core.plugin.factoryloader: Got keys from plugin meta data QList("bradient")
> 
> qt.core.plugin.factoryloader: checking directory path 
> "/opt/cpx/wayland-decoration-client" ...
> 
> qt.core.library: "/usr/lib/plugins/wayland-decoration-client/libbradient.so" 
> loaded library
> 
> qml: Using display
> 
> qml:Name: rdp
> 
> qml:Model: rdp
> 
> qml:Resolution: 1024x768
> 
> qml:Pixel density: 3.94 px/mm
> 
> qml:Device pixel ratio: 1
> 
> qml:Rotation: 0
> 
> qml:Live update: false
> 
> Loaded frontend from:  "qrc:/frontend/small/main.qml"
> 
> planmeca.dbus: CanUpdaterDBusInterface : Waiting for service 
> "com.planmeca.updater"
> 
> planmeca.dbus: CanUpdaterDBusInterface : Waiting for service 
> "com.planmeca.updater"
> 
> planmeca.dbus: CanUpdaterDBusInterface : Waiting for service 
> "com.planmeca.updater"
> 
> planmeca.dbus: CanUpdaterDBusInterface : Waiting for service 
> "com.planmeca.updater"
> 
> planmeca.dbus: CanUpdaterDBusInterface : Waiting for service 
> "com.planmeca.updater"
> 
> planmeca.dbus: CanUpdaterDBusInterface : Waiting for service 
> "com.planmeca.updater"
> 
> planmeca.dbus: CanUpdaterDBusInterface : Waiting for service 
> "com.planmeca.updater"
> 
> planmeca.dbus: CanUpdaterDBusInterface : Waiting for service 
> "com.planmeca.updater"
> 
> planmeca.dbus: CanUpdaterDBusInterface : Waiting for service 
> "com.planmeca.updater"
> 
> planmeca.dbus: CanUpdaterDBusInterface : Waiting for service 
> "com.planmeca.updater"
> 
> planmeca.dbus: CanUpdaterDBusInterface : Waiting for service 
> "com.planmeca.updater"
> 
> planmeca.dbus: CanUpdaterDBusInterface : Waiting for service 
> "com.planmeca.updater"
> 
> /opt/cpx/cpx.sh: line 84:   943 Segmentation fault  ./cpx --rotate=0 "$@"
> 
> root@sm2s-imx8mp:~#
> 
> 
> 
> 
> 
> 
> 
> BR,
> 
> 
> 
> -Matti
> 
> 
> 
> 
> 
> 
> 
> -Original Message-
> From: Marius Vlad 
> Sent: perjantai 13. tammikuuta 2023 16.05
> To: Matti Ristimäki 
> Cc: wayland-devel@lists.freedesktop.org
> Subject: Re: Wayland/weston, Qt and RDP connection...
> 
> 
> 
> On Fri, Jan 13, 2023 at 12:13:41PM +, Matti Ristimäki wrote:
> 
> > Hi,
> 
> Hi,
> 
> >
> 
> > Any tips, where/how to debug RDP related problem with Wayland/Weston. Not 
> > kind of sure if this is Weston problem or Qt problem...
> 
> >
> 
> > Goal:
> 
> > Trying to create a RDP connection to a Qt GUI-application.
> 
> What do you mean exactly?  Don't you mean the other way around?
> 
> 
> 
> Weston starts with the RDP backend and you connect to it with a client that 
> knows about the RDP protocol. Who is the client and who's the server in your 
> case? It is no clear what you are trying to achieve.
> 
> >
> 
> >
> 
> > [Service]
> 
> > # Requires systemd-notify.so Weston plugin.
> 
> > Type=notify
> 
> > EnvironmentFile=/etc/default/weston
> 
> > ExecStart=/usr/bin/weston --log=${XDG_RUNTIME_DIR}/weston.log
> 
> > --modules=systemd-notify.so --modules=screen.share.so
> 
> This might be a long shot but it is screen-share.so (hyphen).
> 
> >
> 
> >
> 
> > Problem:
> 
> > Seems, that the Qt application doesn't start after adding the 
> > "--modules=screen.share.so" to services. And it doesn't start:
> 
> Yeah, same issue here.
> 
> >
> 
> > root@sm2s-imx8mp:~# journalctl -u cpx.service
> 
> > -- Journal begins at Fri 2023-01-13 08:19:03 CET, ends at Fri
> 
> > 2023-01-13 10:26:26 CET. -- Jan 13 08:20:06 sm2s-imx8mp systemd[1]: Started 
> > CPX Control Panel.
> 
> > Jan 13 08:20:06 sm2s-imx8mp cpx.sh[769]: qt.core.logging: Loading 
> > "logging.ini" ...
> 
> > Jan 13 08:20:06 sm2s-imx8mp cpx.sh[769]: Failed to create wl_display
> 
> > (No such file or directory) Jan 13 08:20:06 sm2s-imx8mp cpx.sh[769]:
> 
> > EGL: Warning: No default display support on wayland Jan 13 08:20:06
> 
> > sm2s-imx8mp cpx.sh[769]: qt.qpa.wayland: EGL not available Jan 13 08:20:06 
> > sm2s-imx8mp cpx

Re: Wayland/weston, Qt and RDP connection...

[Marius Vlad]

On Fri, Jan 13, 2023 at 12:13:41PM +, Matti Ristimäki wrote:
> Hi,
Hi,
> 
> Any tips, where/how to debug RDP related problem with Wayland/Weston. Not 
> kind of sure if this is Weston problem or Qt problem...
> 
> Goal:
> Trying to create a RDP connection to a Qt GUI-application.
What do you mean exactly?  Don't you mean the other way around?

Weston starts with the RDP backend and you connect to it with a client
that knows about the RDP protocol. Who is the client and who's the
server in your case? It is no clear what you are trying to achieve.
> 
> 
> [Service]
> # Requires systemd-notify.so Weston plugin.
> Type=notify
> EnvironmentFile=/etc/default/weston
> ExecStart=/usr/bin/weston --log=${XDG_RUNTIME_DIR}/weston.log 
> --modules=systemd-notify.so --modules=screen.share.so
This might be a long shot but it is screen-share.so (hyphen).
> 
> 
> Problem:
> Seems, that the Qt application doesn't start after adding the 
> "--modules=screen.share.so" to services. And it doesn't start:
Yeah, same issue here.
> 
> root@sm2s-imx8mp:~# journalctl -u cpx.service
> -- Journal begins at Fri 2023-01-13 08:19:03 CET, ends at Fri 2023-01-13 
> 10:26:26 CET. --
> Jan 13 08:20:06 sm2s-imx8mp systemd[1]: Started CPX Control Panel.
> Jan 13 08:20:06 sm2s-imx8mp cpx.sh[769]: qt.core.logging: Loading 
> "logging.ini" ...
> Jan 13 08:20:06 sm2s-imx8mp cpx.sh[769]: Failed to create wl_display (No such 
> file or directory)
> Jan 13 08:20:06 sm2s-imx8mp cpx.sh[769]: EGL: Warning: No default display 
> support on wayland
> Jan 13 08:20:06 sm2s-imx8mp cpx.sh[769]: qt.qpa.wayland: EGL not available
> Jan 13 08:20:06 sm2s-imx8mp cpx.sh[769]: qt.qpa.plugin: Could not load the Qt 
> platform plugin "wayland-egl" in "" even though it was found.
> Jan 13 08:20:06 sm2s-imx8mp cpx.sh[769]: This application failed to start 
> because no Qt platform plugin could be initialized. Reinstalling the app>
> Jan 13 08:20:06 sm2s-imx8mp cpx.sh[769]: Available platform plugins are: 
> wayland, offscreen, vnc, minimal, minimalegl, vkkhrdisplay, eglfs, waylan>
> Jan 13 08:20:06 sm2s-imx8mp cpx.sh[764]: /opt/cpx/cpx.sh: line 84:   769 
> Aborted ./cpx --display=LVDS-1 --rotate=0 "$@"
> Jan 13 08:20:06 sm2s-imx8mp systemd[1]: cpx.service: Main process exited, 
> code=exited, status=134/n/a
> Jan 13 08:20:06 sm2s-imx8mp systemd[1]: cpx.service: Failed with result 
> 'exit-code'.
This kind of sounds like there's no Wayland compositor to connect to.
Maybe weston is failing to start because it can't find that module. 

Printing that weston is saying maybe useful. Maybe journalctl -t weston
says something?
> 
> 
> Basic overview:
> 
> Running "first" weston with...
> drm-backend
> screen-share
> Qt-application (CPX Control Panel is the Qt application)
So basically your Qt application is a simple Qt application after all.
> 
> ...and when the screen.share.so starts the "second" Weston, a RDP command is 
> executed from weston.ini*
> rdp-backend
> fullscreen-shell
> 
> 
> *=weston.ini will run the rdp-backend.so
> 
> [screen-share]
> command=@bindir@/weston --backend=rdp-backend.so 
> --rdp-tls-cert=/data/etc/ssh/tls.crt --rdp-tls-key=/data/etc/ssh/tls.key 
> --shell=fullscreen-shell.so --no-clients-resize --no-config
> start-on-startup=true
> 
Right, if you use the screen-share module that would basically run that
command and in turn what would start another weston instance which you
can connect to it with a RDP client. It scrapes off the content and it sends 
it over RDP.
> 
> 
> More about platform(iMX8, Poky (Yocto Project Reference Distro)) and Qt debug 
> print can be found at:
> 
> https://forum.qt.io/topic/142178/qt-qpa-plugin-could-not-load-the-qt-platform-plugin-wayland-egl-in-even-though-it-was-found
> 
> 
> 
> BR,
> 
> 
> -Matti
> 
> 
> Matti Ristimäki
> Test Engineer
> Dental Care Units & CAD/CAM Division
> 
> This e-mail may contain confidential or privileged information and is 
> intended solely for the person to whom it is addressed. If you have received 
> this e-mail in error, please notify the sender immediately and destroy this 
> e-mail. Any unauthorized copying, disclosure or distribution of the material 
> in this e-mail is strictly forbidden. We will not be liable for direct, 
> indirect, special or consequential damages arising from the alteration of 
> this e-mail, or as a result of any virus being passed on or as of 
> transmission of this e-mail in general.


signature.asc
Description: PGP signature

[ANNOUNCE] weston 11.0.1

[Marius Vlad]

Weston 11.0.1, a bug fix release for 11.0.0 is released.

A few potential crash fixes for xwm and ivi-shell have been
pre-emptively addressed as well some warnings seen with ivi-shell
when closing down weston.

kiosk-shell also has seen a few fixes, one of which addresses the activation
of (new) windows which ultimately wouldn't map the windows at all.

A mix of other fixes related to input touch, DRM property and
screenshooer have also landed.

Alexandros Frantzis (2):
  kiosk-shell: Update view transform after activation.
  kiosk-shell: Don't use a modifier for surface activation bindings

Derek Foreman (3):
  xwm: Check size hints in weston_wm_window_is_positioned()
  xwm: Don't crash when setting selection with no seat
  xwm: Propagate selection ownership immediately

Marius Vlad (6):
  doc/sphinx: Make doxygen warn as error depend on meson werror flag
  backend-rdp/rdpclip: Avoid printing negative index
  compositor/shared: Suppress write(2) warnings
  hmi-controller: Add missing removal of destroy listener
  ivi-shell: Move out weston_desktop_shell at the end
  build: bump to version 11.0.1 for the point release

Michael Olbrich (2):
  input: send touch frame event after up event
  backend-wayland: always propagate touch frame event

Michael Tretter (2):
  ivi-shell: fix free in get_layers_under_surface
  ivi-shell: fix cleanup of desktop surfaces

Paul Kocialkowski (1):
  screenshooter: Add SHM buffer destroy listener to avoid invalid memcpy

vanfanel (1):
  Don't change the max_bpc connector prop if mode=current.

git tag: 11.0.1

https://gitlab.freedesktop.org/wayland/weston/uploads/f5648c818fba5432edc3ea63c4db4813/weston-11.0.1.tar.xz
SHA256: a413f68c252957fc3191c3650823ec356ae8c124ccc0cb440da5cdc4e2cb9e57  
weston-11.0.1.tar.xz
SHA512: 
d451230fc260b45db5cf0aa360629e45e72e3b3676c6ec040d6c6549dbb57d05683effd962c3b2d61482b47a6c990d12cc736c896b501d982c8c4d34834c
  weston-11.0.1.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/uploads/bb54e28b5ee47aaccb30a8ffbc31f977/weston-11.0.1.tar.xz.sig


signature.asc
Description: PGP signature

[ANNOUNCE] weston 10.0.3

[Marius Vlad]

Weston 10.0.3 is released with a few of cursor hotspot fixes.

Note that due to some glab issue/bugs I had to manually upload the
tarballs generated by the release script.

Derek Foreman (4):
  Revert "clients/window: Fix animated cursors"
  Revert "clients/window: atomically update pointer cursor"
  clients: Set the hotspot with attach if we already have a valid cursor
  clients: Fix cursors when compositor gives wl_seat before wl_compositor

Marius Vlad (1):
  build: bump to version 10.0.3 for the point release

git tag: 10.0.3

https://gitlab.freedesktop.org/wayland/weston/uploads/4b1cde58d7853553d0371ad7093924aa/weston-10.0.3.tar.xz
SHA256: bba2212ff34a73b4931ae1a9a1f18c21f367c12bd854931673c93ab27c0f4a27  
weston-10.0.3.tar.xz
SHA512: 
89ed679050fa3a96e438a24f719054aed6d581a4eef985d63e617b28693c75b83bdf47f58f874147994604af3ca51b210e0e1253217dee9201001449e039bb9a
  weston-10.0.3.tar.xz
PGP:
https://gitlab.freedesktop.org/wayland/weston/uploads/873d002960428d6ea0afc6d2387c38fc/weston-10.0.3.tar.xz.sig



signature.asc
Description: PGP signature

[ANNOUNCE] Weston bug-fix release -- 11.0.1 and 10.0.3

[Marius Vlad]

Hi everyone,

Last week Simon Ser expressed on IRC, that he's no longer interested
into doing Weston releases, so I'd like to volunteer for that. We have a
few fixes pilling up and I'd like to get these in until the end of the
year, if it is possible.

First, I'd like to personally thank Simon for his contributions and
support all these years. Simon is (still) actively involved with Wayland
and other related projects so he's going to be around, I hope we can 
further interact and collaborate.

Secondly, I suggested last week doing a bug-fix release for Weston 11
(11.0.1), and with it, one for Weston 10 (10.0.3). I'd like to continue
supporting at least one version behind our current development branch.

I'm looking at doing that this point release, the third week of December
(12-16), with a tentative for Dec 14, unless obviously some other issues
don't further pile up.

Finally, if you would like to see anything else getting in until then, and
qualifies as a bug-fix, either open a MR against that respective branch or
use the label 'Backport to weston 11' for closed MRs which landed into 
main branch, and which I might have missed.


signature.asc
Description: PGP signature

Re: Weston 8: kiosk-shell background is black but should be grey

[Marius Vlad]

On Tue, Oct 04, 2022 at 11:07:11AM +0100, Terry Barnaby wrote:
> On 04/10/2022 09:56, Alexandros Frantzis wrote:
> > On Tue, Oct 04, 2022 at 08:55:22AM +0100, Terry Barnaby wrote:
> > >  From what I can see the kiosk-shell in Weston 9.0 should draw a grey 
> > > (0.5,
> > > 0.5, 0.5) solid colour background. However on my NXP embedded system it
> > > shows as black.
> > > 
> > > Should the kiosk-shell in Weston 9.0 actually draw grey ?
> > > 
> > > If so is there some configuration I'm missing or is there a bug with that
> > > release ?
> > > 
> > > Terry
> > Hi Terry,
> > 
> > kiosk-shell until some point after 9.0.0 (until commit 73aaf14e to be
> > precise), has a hardcoded grey background. I just verified this works
> > fine with 9.0.0, at least with an Intel GPU.
> > 
> > The aforementioned commit changes the default background to black and
> > allows reading a background color value from the .ini file, like
> > desktop-shell does.
> > 
> > If you are not seeing a grey background, could it be the case that the
> > Weston version you are using is not actually pure 9.0.0 but is based on
> > some commit after 9.0.0 (so really version 9.0.9x) that also includes the
> > background-color support?
> > 
> > The first lines of your Weston log should provide information about the
> > exact version/build you are running. What do the lines say?
> > 
> > In the email subject you wrote "Weston 8", is this a typo?
> > 
> > Thanks,
> > Alexandros
> 
> Hi Alexandros,
> 
> Thanks for the reply, Yes, the "Weston 8" in the subject was a typo, sorry.
> 
> The Weston 9 used is that in the NXP Yocto hardknot release.
> 
> Actually looking at the Yocto sources for that, it is actually based on an
> NXP GIT at: git://source.codeaurora.org/external/imx/weston-imx.git,
> e73c641e076aa68e8ef69dbd56c7a252117b2c83 with some additional minor patches.
> I assumed it was based directly on the upstream Weston GIT. So as the
> background colour should be grey in the upstream 9.0.0 release I suspect
> some issues in the NXP modifications and/or hardware interface.
> 
> So I will ask on the NXP forums on this.
I see you're using g2d, maybe try turning that off and see if it's still
black? Would be really nice if could update this thread once you find
out the issue, it could help others too.
> 
> But just for info:
> 
> Looking at the kiosk-shell code it does not have the config file
> background-color support. In general I have no issues with Weston on this
Support for changing the background was added, like Alexandros said, 
in 9.0.x which made in into weston 10.

Fyi, code that added background intially had an issue where the two
channels were swapped, but was rectififed a bit later on 
(but that's fixed in weston 10).
> platform, its just when trying to implement a switch of the output device
> for a full screen application, I need to redraw the background on the old
> output and I found that this wasn't working and it actually should have been
> grey anyway.
> 
> The first log lines say:
> 
> Date: 2022-10-04 BST
> [10:39:31.437] weston 9.0.0
>    https://wayland.freedesktop.org
>    Bug reports to:
> https://gitlab.freedesktop.org/wayland/weston/issues/
>    Build: lf-5.10.52-2.1.0-rc2-0-ge73c641e+
> [10:39:31.451] Command line: /usr/bin/weston --log=/run/user/0/weston.log
> --modules=systemd-notify.so
> [10:39:31.452] OS: Linux, 5.10.52-lts-5.10.y-ds200i-7-ge17e4a8d84dd, #34
> SMP PREEMPT Wed Aug 31 09:58:42 BST 2022, aarch64
> [10:39:31.461] Using config file '/etc/xdg/weston/weston.ini'
> [10:39:31.462] Output repaint window is 16 ms maximum.
> [10:39:31.469] Loading module '/usr/lib/libweston-9/drm-backend.so'
> [10:39:31.487] initializing drm backend
> [10:39:31.496] logind: session control granted
> [10:39:32.513] dbus connection send fail and will retry
> [10:39:32.518] using /dev/dri/card1
> [10:39:32.518] DRM: supports atomic modesetting
> [10:39:32.518] DRM: does not support GBM modifiers
> 
> 
> /etc/xdg/westong.conf has:
> 
> [core]
> #gbm-format=argb
> #gbm-format=rgb565
> idle-time=0
> use-g2d=1
> xwayland=true
> repaint-window=16
> #enable-overlay-view=1
> 
> # DS200i startup
> shell=kiosk-shell.so
> #shell=ds200i-shell.so
> #shell=fullscreen-shell.so
> 
> [shell]
> #size=1920x1080
> 
> [libinput]
> touchscreen_calibrator=true
> 
> #[output]
> #name=HDMI-A-1
> #mode=1920x1080@60
> #transform=rotate-90
> 
> #[output]
> #name=HDMI-A-2
> #mode=off
> #   WIDTHxHEIGHT    Resolution size width and height in pixels
> #   off Disables the output
> #   preferred   Uses the preferred mode
> #   current Uses the current crt controller mode
> #transform=rotate-90
> 
> [screen-share]
> command=@bindir@/weston --backend=rdp-backend.so --shell=fullscreen-shell.so
> --no-clients-resize
> 
> [launcher]
> icon=/home/root/.nxp-demo-experience/icon/icon_demo_launcher.png
> path=/usr/bin/demoexperience
> 
> [launcher]
> icon=/usr/share/weston/terminal.png

Re: Dual Independent displays with NXP i.MX8QM SoC

[Marius Vlad]

Hi,

Keep in mind that Wayland is a protocol, and all your questions seem to 
be related to Weston, which is one of the compositors implementing it. 
Some of the them do share some common functionality, and would work 
similarity, but need to have that mind.


On 12/13/21 11:55, Abdul Redwan wrote:

Hello Wayland Developer Team,
We are working on dual display use case based on i.MX8QM SoC for an 
Automotive Rear Seat Entertainment application which has Audio/Video 
playback supporting two users in parallel. As well defined, we could 
achieve extended display with Wayland/Weston service (Unable to choose 
the location of the secondary display for the applications except with 
the help of mouse pointer) but we need dual Independent displays hence 
tried below options without any luck


1. Kiosk shell (We believe it allows to locate the display with app-ids 
field under output)


This works, but not with all applications. See 
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/611 for 
more details, which fixes it in other different circumstances. 
Obviously, applications need to have an app_id set. Also, just a single 
weston instance.


2. Two Weston service (is this only possible with two DRM devices? not 
with one?? drm-backend seems to be crashing for the second service)


You set-up an ENV{ID_SEAT}, for which you assign a graphics card which 
you can then pass to weston. So then you have two weston instances for 
each seat (each with its own graphics card, and potentially input 
devices). Some slightly related documentation to that can be found at 
https://wayland.pages.freedesktop.org/weston/toc/running-weston.html


But you don't really have two graphics card, just one. You have two
DRM devices, one being the display, one being the GPU, commonly found in 
SoCs.



3. Segregating user points for each display like dedicating touch inputs 
for each display in kms.conf for QT Wayland, ivi-shell, etc


What are user points? You should be able to specify which inputs
reach which outputs by using proper udev rules, just like I've mentioned 
above. In that link there's actually an example on how to assign a 
particular input to a particular output.




We aren't very sure if above methods we tried is properly executed, any 
other methods we have missed or not if we could get some working 
logs/steps so that we can verify the same. Also, if you could let us 
know if there are any limitations with dual independent display wrt 
Native Wayland/Weston (Both users in Parallel accessing two displays 
able to do extensive Audio/Video playback) it would be helpful


It seems you might be looking at logical seats (what I've suggested 
previously), or potentially have a look at DRM lease functionality where 
a compositor can lease to other clients (well maybe potentially to other
compositors) some DRM resources. We have a protocol for that: 
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/drm-lease/drm-lease-v1.xml 
but in weston there's no implementation for it. wlroots seem to be have 
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/2929 
though.




Thanks,
Redwan

Re: [ANNOUNCE] Weston 10.0 release schedule

[Marius Vlad]

On Tue, Nov 30, 2021 at 04:37:09PM +, Simon Ser wrote:
> Hi all,
Hi,
> 
> Here is the release schedule for Weston 10.0, the next major version:
> 
> - Alpha: December 14th, in 2 weeks
> - Beta: January 11th
> - RC1: January 25th
> - First possible release: February 1st
> 
> There is a one month gap between alpha and beta to accommodate for Christmas
> holidays.
> 
> Package maintainers are encouraged to pick up the pre-releases to make
> sure packaging can be tested (and fixed) before the stable release.
> 
> Let me know if there's something in particular you want merged for 10.0.
Fyi, though a bit late, I've updated the 10.0.0 milestone (w/ the 14'th of
December) and tagged a few things I'd like to see merged for 10.0.0. 

It's for the signal corruption list we've been seeing for time now + some
changes for kiosk-shell related to moving app_ids to different outputs
(and some client minor bits).

A direct link to that:
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests?scope=all=opened_title=10.0.0


> 
> Thanks,
> 
> Simon


signature.asc
Description: PGP signature

Re: Client-driven orientation change in Weston

[Marius Vlad]

On Mon, Aug 02, 2021 at 10:58:39AM +0200, Guillermo Rodriguez Garcia wrote:
> Hi,
Hi,
> 
> I am asking this because I saw the following from Pekka Paalanen in another
> thread:
> 
> > [...] Can the compositor do it all on its own, does the client need to
> synchronise to the orientation change, does the client need to drive
> the orientation change, etc.
> 
> In Weston I am currently controlling the orientation via transform=xxx in
> the .ini file.
> 
> Is it possible to drive this change dynamically from the client instead?
It is, we have a sort-of working WIP for it, with the help of a private
protocol [1]. With that there's also a simple client that can request an
output rotation, interactively, as well as using an accelerometer that
detects an orientation change and uses that protocol to signal it. 
More details could be find at [2]. Note, that is still need of a polish,
but should work with regular wayland clients.

[1] 
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/480/diffs?commit_id=09d7a79a9a18ab48317833680d550a483a5c92b4
[2] https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/480
> 
> BR,
> 
> Guillermo Rodriguez Garcia
> guille.rodrig...@gmail.com


signature.asc
Description: PGP signature

Re: libweston as a DRM lease lessee

[Marius Vlad]

On Tue, Feb 02, 2021 at 11:28:46AM +0200, Pekka Paalanen wrote:
> On Tue, 2 Feb 2021 00:39:30 +0900
> Damian Hobson-Garcia  wrote:
> 
> > Hi Pekka,
> > 
> > Thank you for your comments.
> > 
> > On 2021/02/01 19:34, Pekka Paalanen wrote:
> > > On Mon, 1 Feb 2021 18:19:29 +0900
> > > Damian Hobson-Garcia  wrote:
> > >  
> > >> Hi all,
> > >>
> > >> I am working on adding DRM lease support to a libweston based compositor.
> > >> The compositor will be a client (lessee) that will display output to a
> > >> DRM lease that
> > >> is created by another (lessor) process, so this is kind of the opposite
> > >> direction to the DRM lease patches
> > >> that were submitted a while back [1].
> > >>
> > >> The motivation is to be able to run multiple instances of weston w/ DRM
> > >> backend, where each instance
> > >> has direct access to a subset of the DRM connectors.  Each instance
> > >> could, for example, run in a separate container,
> > >> with minimal host interaction.
> > >>
> > >> In this configuration the DRM lease would be received from a UNIX domain
> > >> socket connection to the lessor,
> > >> so would not discoverable via udev, in the same way that DRM device
> > >> nodes normally are.
> > >>
> > >> I think that I would need to make changes to the compositor-drm, but if
> > >> possible,
> > >> I'd like to make those changes generic enough to be useful upstream as
> > >> well, so I was hoping to get some feedback before possibly heading down
> > >> a wrong path.  
> > > Hi,
> > >
> > > that is an interesting goal. How will this "nested" Weston/DRM get
> > > input?  
> > 
> > This is still uncertain.  One option is of course to bind mount input 
> > devices into the
> > container, but I know that there are problems with providing the
> > seat information that libinput needs (unless that has changed recently).
> > I haven't really looked into how to address that yet.
> 
> Are you referring to not having access to udev daemon (the udev
> properties mechanism) in the container?
> 
> If yes, there might be another problem below.
> 
> > >>   From what I can tell, I need to:
> > >>
> > >> 1. Get the DRM lease file descriptor, given an identifier (In my DRM
> > >> lease case this is a name that maps to a socket path)
> > >> 2. Get a udev_device struct for the device corresponding to the above fd
> > >> (via the major:minor numbers)
> > >>
> > >> I think that #1 can be implemented in either via the launcher API (a new
> > >> launcher type?) or by adding an option for
> > >> the compositor to provide the fd, but #2 seems like it should be in
> > >> compositor-drm, right?  
> > > Hmm, what would an udev_device be needed for? Hotplug events?  
> > 
> > Yes, hotplug events.  My hope is that it would work that same as for the 
> > regular
> > DRM device nodes.  I guess that some modifications to the hotplug code 
> > may be
> > necessary to deal with events on connectors that are not included in the
> > DRM lease.
> 
> Hotplug events are udev events, and traditionally they do not name any
> connetor or anything. They only say "something might have changed with
> this DRM device, it would be better for you to re-scan the whole
> device to see what changed". Weston implements this.
> 
> I'm not exactly sure how those events are delivered, do you need a udev
> daemon running? Weston uses the udev_monitor API for it currently which
> I think requires udevd maybe?
> 
> An alternative could be to deliver the equivalent of hotplug events
> through your DRM leasing protocol.
> 
> I can't say anything for certain, but as a first try, I'd probably
> attempt writing a new launcher backend for weston, parallel to the
> existing launcher backends logind, weston-launch and direct. The device
> discovery code is not in the launcher backend but in the DRM-backend
> proper though, so I guess you indeed may need to do something about
> that.
Would this mean modifying the launcher API to pass down a
file-descriptor directly, or would that happen in the launcher itself
(assuming that would be reason for writing a new launcher -- somehow use some
helpers to retrieve the lease fd in the container).

Wouldn't be easier to just pass down the lease fd to the DRM-backend, as
config option, and handle the mapping itself in the compositor rather than in
libweston?
> 
> You seem to be on the right track from what I can tell.
> 
> As for other use cases or running inside containers, nothing comes to
> my mind, but OTOH the concept of something like "a full desktop in a
> container" might be attractive to some? Or using a multi-head gfx card
> for multi-seat, to avoid needing to have one gfx card per seat.
> 
> 
> Thanks,
> pq



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



signature.asc
Description: PGP signature
___
wayland-devel mailing list

Re: Weston-6.0.0 fails to run with pixman on IMX8

[Marius Vlad]

On Wed, Jul 29, 2020 at 04:22:07PM +0930, Sami Md wrote:
> Hi,
Hi,

Most likely you're using a modified version of weston, and a rather old
one. Passing `--use-pixman` option to the DRM-backend is not conditioned
by additional macros which are sprinkle's by the vendor in that version
you're using. If you can get a hold of the upstream version of weston
you shouldn't have any problems using the pixman renderer. But also
even that older version should work. Probably you'll need to reach out to
the vendor for additional  help.

> I am trying to run Weston-6.0.0 on IMX8mqev Yocto Linux.
> 
> I executed below command to run the Weston-6 on TTY-7 using pixman.
> 
> # weston --tty=7 --use-pixman
> 
> But I got below error:
> root@imx8mqevk:~# weston --tty=7 --use-pixman
> Date: 2020-07-29 UTC
> [06:01:24.327] weston 6.0.0
>https://wayland.freedesktop.org
>Bug reports to:
> https://gitlab.freedesktop.org/wayland/weston/issues/
>Build: 6.0.0-33-g81b11811-dirty compositor-drm: Bypass the
> check of the libinput (2019-06-06 17:54:16 +0800)
> [06:01:24.327] Command line: weston --tty=7 --use-pixman
> [06:01:24.327] OS: Linux, 4.19.35+ge4452f4458e4, #1 SMP PREEMPT Thu Jul 23
> 23:37:43 ACST 2020, aarch64
> [06:01:24.328] Using config file '/etc/xdg/weston/weston.ini'
> [06:01:24.328] Output repaint window is 34 ms maximum.
> [06:01:24.328] Loading module '/usr/lib/libweston-6/drm-backend.so'
> [06:01:24.350] initializing drm backend
> [06:01:24.351] logind: failed to get session seat
> [06:01:24.351] logind: cannot setup systemd-logind helper (-61), using
> legacy fallback
> [06:01:24.359] using /dev/dri/card0
> [06:01:24.359] DRM: supports universal planes
> [06:01:24.359] DRM: supports atomic modesetting
> [06:01:24.359] DRM: supports picture aspect ratio
> [06:01:24.359] Loading module '/usr/lib/libweston-6/gl-renderer.so'
> [06:01:24.410] EGL client extensions: EGL_EXT_client_extensions
>EGL_EXT_platform_base EGL_KHR_platform_wayland
>EGL_EXT_platform_wayland EGL_KHR_platform_gbm
> [ 1] Failed to open device: No such file or directory, Try again...
> [ 2] Failed to open device: No such file or directory, Try again...
> [ 3] Failed to open device: No such file or directory, Try again...
> [ 4] Failed to open device: No such file or directory, Try again...
> [ 5] _OpenDevice(1228): FATAL: Failed to open device, errno=No such
> file or directory.
> [ 6] Failed to open device: No such file or directory, Try again...
> [ 7] Failed to open device: No such file or directory, Try again...
> [ 8] Failed to open device: No such file or directory, Try again...
> [ 9] Failed to open device: No such file or directory, Try again...
> [10] _OpenDevice(1228): FATAL: Failed to open device, errno=No such
> file or directory.
> root@imx8mqevk:~# [  690.668220] random: crng init done
> [  690.668247] random: 7 urandom warning(s) missed due to ratelimiting
> [ 1824.050168] audit: type=1006 audit(1596004201.751:4): pid=3134 uid=0
> old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=3 res=1
> 
> my weston.ini
> ---
> root@imx8mqevk:~# cat /etc/xdg/weston/weston.ini
> [core]
> repaint-window=34
> 
> weston.log
> --
> root@imx8mqevk:~# cat /var/log/weston.log
> Date: 2020-07-29 UTC
> [05:55:45.406] weston 6.0.0
>https://wayland.freedesktop.org
>Bug reports to:
> https://gitlab.freedesktop.org/wayland/weston/issues/
>Build: 6.0.0-33-g81b11811-dirty compositor-drm: Bypass the
> check of the libinput (2019-06-06 17:54:16 +0800)
> [05:55:45.407] Command line: /usr/bin/weston --log=/var/log/weston.log
> [05:55:45.407] OS: Linux, 4.19.35+ge4452f4458e4, #1 SMP PREEMPT Thu Jul 23
> 23:37:43 ACST 2020, aarch64
> [05:55:45.410] Using config file '/etc/xdg/weston/weston.ini'
> [05:55:45.412] Output repaint window is 34 ms maximum.
> [05:55:45.414] Loading module '/usr/lib/libweston-6/drm-backend.so'
> [05:55:45.478] initializing drm backend
> [05:55:45.504] logind: session control granted
> [05:55:45.528] using /dev/dri/card0
> [05:55:45.528] DRM: supports universal planes
> [05:55:45.529] DRM: supports atomic modesetting
> [05:55:45.529] DRM: supports picture aspect ratio
> [05:55:45.529] Loading module '/usr/lib/libweston-6/gl-renderer.so'
> [05:55:45.684] EGL client extensions: EGL_EXT_client_extensions
>EGL_EXT_platform_base EGL_KHR_platform_wayland
>EGL_EXT_platform_wayland EGL_KHR_platform_gbm
> 
> 
> DRM used : VIRTIO-GPU DRM driver
> root@imx8mqevk:~# ls -l /dev/dri/card0
> crw-rw 1 root video 226, 0 Jul 29 05:55 /dev/dri/card0
> 
> dmesg output with drm
> 
> root@imx8mqevk:~# dmesg | grep drm
> [0.762194] [drm] virgl 3d acceleration not supported by host
> [0.772082] [drm] number of scanouts: 1
> [0.772147] [drm] number of cap sets: 0
> [0.802799] virtio_gpu virtio4: fb0: virtiodrmfb 

Re: Multiple HW plane enable BKM in open source Weston

[Marius Vlad]

Hi,

Well, if the overlay (which apparently is underlay in your case) plane
supports YUYV you don't any kind of color conversion between them. Pekka
already made this pretty clear: you need to match out what pixel format
you're using with that of the overlay plane. There's drm_info from Scott
(https://github.com/ascent12/drm_info) or modetest from libdrm to check
what your HW supports.

While weston doesn't properly support underlays, (and this is on-going
issue at the moment) weston if capable to place multiple views in
multiple HW planes.

For your particular use case, the only to achieve that, is that the main
UI has to be alpha blended with the (view) one below when you want to
display the video in overlay.

Do note that for a view to reach the primary plane the view has to cover
the entire output. As we don't properly support underlays (which
requires additional work to reveal the view underneath the view assigned
in the primary plane) you'll need to have the video in the overlay
matching the entire output as well.

Not only that, but for all of this to work, you'll need to bind to
wl_subcompositor interface and with it, to use sub-surfaces for your
application to behave as one, otherwise you ran into the problem of the
main UI being fullscreen which gets injected an additional black surface
view below it, and you won't be able to display anything underneath it,
even if even if you (locally) alpha blended it.

But also do note, this might not be that easily achievable due to HW
constrains, as adding alpha blending to a plane increases the BW
necessary by the HW which will be easily saturated when combined with
another plane (overlay), so weston will then go into compositing mode of
rendering. You'll need to verify that with `drm-debug' scope if that
happens.

PS: I've interchanged overlay with underlay here so adjust accordingly
when reading.

On 1/3/20 12:47 PM, Tang, Jun wrote:
> Thanks Marius/pq for the quick comments. 
> 
> My use case is something like video playback. I would like to put video 
> content on lower overlay and UI on upper plane. According to your feedback, 
> seems not easy for me to do that. 
> First of all, my video content should be YUYV format. Secondly even I do some 
> CSC to make it as AR24, since the UI is always AR24 also. Looks like I still 
> can't clearly put UI and video content on separate planes without any code 
> changes to the compositor. 
> 
> -James
> 
> -Original Message-
> From: Pekka Paalanen [mailto:ppaala...@gmail.com] 
> Sent: Tuesday, December 31, 2019 8:41 PM
> To: Tang, Jun 
> Cc: Marius Vlad ; 
> wayland-devel@lists.freedesktop.org
> Subject: Re: Multiple HW plane enable BKM in open source Weston
> 
> On Mon, 30 Dec 2019 11:29:02 +0200
> Marius Vlad  wrote:
> 
>> Hi,
>>
>> Yes, overlays are supported in weston but do note that this mailing 
>> list is also about other compositors and the protocol itself.
>>
>> Clients do not specify where to "place" the surfaces, the compositor 
>> back-end is the only one who can make those decisions based on what HW 
>> is capable of, what is currently in use, and what other surfaces are 
>> currently being displayed. The back-end, in weston, got a new face 
>> lift, and exposes a little bit better the conditions in which a view 
>> can make it to a HW plane: is a
>> (HW) plane available, is the pixel format suitable, etc. If you feel  
>> adventurous that should be place to learn more.
>>
>> Together with this face lift weston can now place an AR24 type of 
>> pixel buffer on the overlay plane, so if HW capable of using that 
>> pixel format should be able to place the view into an overlay plane. 
>> I'm mentioning this because `weston-simple-egl` will default to that 
>> when started, and a fairly recent i915 driver should have an overlay 
>> supporting that.
>>
>> We have in weston debug scopes capable of displaying large amounts of 
>> debug information. Start weston with with `--debug` and use the client 
>> `weston-debug` with `-a` to list all current debug scopes. 
>> `drm-backend' is the one useful in this case. It will display which 
>> views made to it a HW plane, or why was the reasons for not doing so. 
>> Should be able to correlate a bit this information with decision tree 
>> currently done in weston.
>>
>> Hope this helps.
>>
>> On 12/30/19 4:05 AM, Tang, Jun wrote:
>>> Hi Wayland Experts,
>>>
>>> I checked the open source version of Weston code, seems there is 
>>> atomic mode setting API to add new plane properties. I believe 
>>> overlay HW plane should be supported by Weston. But as a newbie for 
>>> Wayland. Still not sure how application can put their 

Re: Multiple HW plane enable BKM in open source Weston

[Marius Vlad]

Hi,

Yes, overlays are supported in weston but do note that this mailing list
is also about other compositors and the protocol itself.

Clients do not specify where to "place" the surfaces, the compositor
back-end is the only one who can make those decisions based on what HW
is capable of, what is currently in use, and what other surfaces are
currently being displayed. The back-end, in weston, got a new face lift,
and exposes a little bit better the conditions in which a view can make
it to a HW plane: is a (HW) plane available, is the pixel format
suitable, etc. If you feel  adventurous that should be place to learn more.

Together with this face lift weston can now place an AR24 type of pixel
buffer on the overlay plane, so if HW capable of using that pixel format
should be able to place the view into an overlay plane. I'm mentioning
this because `weston-simple-egl` will default to that when started, and
a fairly recent i915 driver should have an overlay supporting that.

We have in weston debug scopes capable of displaying large amounts of
debug information. Start weston with with `--debug`  and use the client
`weston-debug` with `-a` to list all current debug scopes. `drm-backend'
is the one useful in this case. It will display which views made to it a
HW plane, or why was the reasons for not doing so. Should be able to
correlate a bit this information with decision tree currently done in
weston.

Hope this helps.

On 12/30/19 4:05 AM, Tang, Jun wrote:
> Hi Wayland Experts,
> 
> I checked the open source version of Weston code, seems there is atomic mode 
> setting API to add new plane properties. I believe overlay HW plane should be 
> supported by Weston. But as a newbie for Wayland. Still not sure how 
> application can put their surface on specified HW plane. Could you please 
> share me some BKM on Wayland client side? Any quick ideas would be 
> appreciated!
> 
> -James
> 
> 
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

-- 
Marius Vlad



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] unstable/linux-dmabuf: Add 'direct_display' flag

[Marius Vlad]

On 11/14/19 12:20 AM, Drew DeVault wrote:
> Can you elaborate more on non-DRM use-cases? Most compositors are
> already going to use direct scan-out as much as possible, and can make
> reasonably well informed choices about when to do so. For example,
> fullscreen surfaces will generally always be scanned out if possible.

Unfortunately that's only partially correct, the buffer will
(eventually) be scanned out directly, but there's nothing preventing the
compositor to first import into the GPU. That flag assures the client
that (the above) will not never happen.

Really old platforms like i.MX51/i.MX53 have limited bandwidth to
accommodate both video decoding/compositing/rendering and would greatly
benefit from having to ability to bypass the GPU entirely. There's even
lower powered boards which don't have a 3D core at all, but still
capable of video display through a display controller. These are some
potential targets which could benefit from having this available.

> More interesting approaches could include intelligently picking the most
> frequently updated buffers to be placed on planes, or the most optimal
> arrangement for a given combination of pixel formats.
> 
> In addition, the implication that the compositor shouldn't do things
> like letting the user take screenshots when views like this are being
> shown is a chilling effect on non-DRM use-cases, in which taking a
> screenshot is a perfectly reasonable thing to do.

I've seen this raised by Scott, have to admit I'm not aware of the
issues with the screenshots are, nor do I see how this flag would
influence that behaviour. I'll sure take a look to see what's the issue
about it.

> 
> I don't really like the idea of DRM-enabling features being added to
> linux-dmabuf with this level of justification for non-DRM use-cases.
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

-- 
Marius Vlad



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] unstable/linux-dmabuf: Add 'direct_display' flag

[Marius Vlad]

On 11/14/19 6:05 AM, Scott Anderson wrote:
>>
> 
> Has any thought been into how this would need to interact with
> dmabuf-hints[1]? Without that, it seems like it would be a total
> crapshoot for clients to try and use this flag, since they have no idea
> what formats+modifers the display controller supports, and instead only
> has the list that the GPU supports.
> dmabuf-hints would also need to explicitly state that a tranche of
> formats+modifiers are supported for this flag.

Well I'm not aware of that hint extension, but I think this wasn't taken
into consideration because it isn't the same thing. There's no assurance
from the compositor that the buffer will not read/be imported by the
GPU. A hint is merely a hint. The compositor can abide or not by that.
This flag will explicitly close the client connection if the buffer
can't be scanned out when this flag is passed.

Regarding the screenshot bit not sure what is the concern here. Are you
afraid you won't able to take screenshots? The placeholder graphics is
in place only if view to which the buffer is attached can no longer be
assigned to a HW plane.

It would be nice to know what basic functionality will this break, as I
not aware of any.

-- 
Marius Vlad



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

[PATCH] unstable/linux-dmabuf: Add 'direct_display' flag

[Marius Vlad]

Flag used to tell the compositor that it should avoid touching the
dmabuf buffer and forward it directly to the display controller.

Most likely this flag can be used together with the content-protection
protocol. It assures the client that the compositor will never handle
the buffer over to the GPU but instead it will forward it straight to
the display controller.

While content-protection protocol should be sufficient to restrict the
content on certain displays, on certain hardware platforms the GPU is
not a secure-path link in the secure-content-path chain, and as such,
this flag would be necessary to avoid passing the dmabuf buffer
over to the GPU altogether. GPUs reading the dmabuf residing in a
specially designed memory zone would be seen as an illegal memory access.

Other example include video players which might need this flag passed
down to avoid doing any composition, thus having an improvement of
bandwidth usage and performance. Set-up boxes with dedicated video
players could use this facility alongside the Pixman renderer, is
another potential example of why this flag would be useful.

Bumps zwp_linux_dmabuf_v1 and zwp_linux_buffer_params_v1 to version 4.

Signed-off-by: Marius Vlad 

---
This patch initially started as fork at
https://gitlab.freedesktop.org/marius.vlad0/wayland-protocols/merge_requests/3

This flag was used to be called 'no_gpu_import' but 'direct_display'
should better reflect its name and purpose.

Lastly, a WIP for the implementation of this flag for weston is at
https://gitlab.freedesktop.org/wayland/weston/merge_requests/298, which
should follow up closely.
---
 .../linux-dmabuf/linux-dmabuf-unstable-v1.xml | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml 
b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
index b43e81c..5b4b1e6 100644
--- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
+++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
@@ -2,7 +2,7 @@
 
 
   
-Copyright © 2014, 2015 Collabora, Ltd.
+Copyright © 2014, 2015, 2019 Collabora, Ltd.
 
 Permission is hereby granted, free of charge, to any person obtaining a
 copy of this software and associated documentation files (the "Software"),
@@ -24,7 +24,7 @@
 DEALINGS IN THE SOFTWARE.
   
 
-  
+  
 
   Following the interfaces from:
   
https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
@@ -149,7 +149,7 @@
 
   
 
-  
+  
 
   This temporary object is a collection of dmabufs and other
   parameters that together form a single logical buffer. The temporary
@@ -229,6 +229,7 @@
   
   
   
+  
 
 
 
@@ -254,6 +255,14 @@
 'bottom_first' is specified. It is undefined whether 'bottom_first'
 is ignored if 'interlaced' is not set.
 
+Flag 'direct_display' tells the compositor not to import it to the GPU
+in order to bypass it entirely, such that the buffer will be directly
+scanned-out by the display controller. If HW is not capable/or there
+aren't any available resources to directly scan-out the buffer, a
+placeholder should be installed in-place by the compositor. The
+compositor may perform checks on the dmabuf and refuse to create a
+wl_buffer if the dmabuf seems unusable for being used directly.
+
 This protocol does not convey any information about field rate,
 duration, or timing, other than the relative ordering between the
 two fields in one buffer. A compositor may have to estimate the
-- 
2.24.0

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

Re: [PATCH v8] unstable/drm-lease: DRM lease protocol support

[Marius Vlad]

Thanks for pushing this further!

Added some comments below.

On 11/7/19 4:59 PM, Drew DeVault wrote:
> From: Marius Vlad 
> 
> DRM leasing is a feature which allows the DRM master to "lease" a subset
> of its DRM resources to another DRM master via drmModeCreateLease, which
> returns a file descriptor for the new DRM master. We use this protocol
> to negotiate the terms of the lease and transfer this file descriptor to
> clients.
> 
> In less DRM-specific terms: this protocol allows Wayland compositors to
> give over their GPU resources (like displays) to a Wayland client to
> exclusively control.
> 
> The primary use-case for this is Virtual Reality headsets, which via the
> non-desktop DRM property are generally not used as desktop displays by
> Wayland compositors, and for latency reasons (among others) are most
> useful to games et al if they have direct control over the DRM resources
> associated with it. Basically, these are peripherals which are of no use
> to the compositor and may be of use to a client, but since they are tied
> up in DRM we need to use DRM leasing to get them into client's hands.
> 
> Signed-off-by: Marius Vlad 
> Signed-off-by: Drew DeVault 
> ---
> v8 changes lease_manager -> lease_device on the grounds that managers
> are singletons and this interface has one global per DRM device.
> 
> The logind concern was found to be valid - logind will not let you open
> the DRM node twice. However, for a non-privileged node like the one
> called for here, most compositors in use today will be able to use
> drmGetDeviceNameFromFd2 and open the file themselves. Regardless, the
> need for improvement in logind does not affect the viability of this
> protocol, and I think that v8 is ready to be applied.
> 
> Quick reminder that, for the sake of the corresponding Vulkan extension,
> we'd like to fast track this protocol to stability once we've agreed on
> the unstable version.
> 
>  Makefile.am  |   1 +
>  unstable/drm-lease/README|   5 +
>  unstable/drm-lease/drm-lease-unstable-v1.xml | 246 +++
>  3 files changed, 252 insertions(+)
>  create mode 100644 unstable/drm-lease/README
>  create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 345ae6a..d9fff89 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -4,6 +4,7 @@ unstable_protocols =  
> \
>   unstable/pointer-gestures/pointer-gestures-unstable-v1.xml  
> \
>   unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
> \
>   unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
> \
> + unstable/drm-lease/drm-lease-unstable-v1.xml
> \
>   unstable/text-input/text-input-unstable-v1.xml  
> \
>   unstable/text-input/text-input-unstable-v3.xml  
> \
>   unstable/input-method/input-method-unstable-v1.xml  
> \
> diff --git a/unstable/drm-lease/README b/unstable/drm-lease/README
> new file mode 100644
> index 000..16f8551
> --- /dev/null
> +++ b/unstable/drm-lease/README
> @@ -0,0 +1,5 @@
> +Linux DRM lease
> +
> +Maintainers:
> +Drew DeVault 
> +Marius Vlad 

Should probably use the new mail here.

> diff --git a/unstable/drm-lease/drm-lease-unstable-v1.xml 
> b/unstable/drm-lease/drm-lease-unstable-v1.xml
> new file mode 100644
> index 000..50a310b
> --- /dev/null
> +++ b/unstable/drm-lease/drm-lease-unstable-v1.xml
> @@ -0,0 +1,246 @@
> +
> +
> +  
> +Copyright © 2018 NXP
> +Copyright © 2019 Status Research  Development GmbH.
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +THE 

Re: Why so many Weston APIs were moved to libweston-internal.h

[Marius Vlad]

Hi Xichen,

The main reason for doing this move/split is because, over the years, a
lot of helper API has crawled into libweston, making it quite in large
size and hard to reason about the symbols usefulness. That header was/is
a catch-all for ``where do I put this symbol declaration?''.

The split is an attempt to re-organize a bit the front-facing API which
users can directly use (Weston is a user of libweston -- but others
might also be) and internal API (which is used only internally by
libweston itself).

There's still a bit of work like trying to make some of the symbols
opaque, or have some kind of categorization by class/functionality.
There's also an orthogonal reason behind this as this split/movement of
API is related to the documentation process of the library itself.

Please see the discussion/comments over
https://gitlab.freedesktop.org/wayland/weston/merge_requests/227. It
should provide some insight on matter as well.

On 8/16/19 8:15 PM, Sichem Zhou wrote:
> Hi weston developers,
> 
> I noticed the new weston(since version 6.0.91), it introduced a new
> internal header `libweston-internel.h`. Many useful APIs for compositor
> writers were moved here.
> 
> For example, personally I heavily use temporary binding thus I use
> `weston_binding_destroy` to remove those bindings once their jobs are done.

I myself found that I've migrated a symbol which I needed exposed for
Weston so I had to put back in to the public API.

> 
> Right now I can still declare those functions but once those API are
> internal, they are subjected to changes or removal thus breaks the linkage
> for compositor writers. I am wondering Is it possible to move those
> functions back to public?

Yes, of course, if that's the case, please submit a MR for those symbols
which you think are useful.

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

-- 
Marius Vlad



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] unstable/drm-lease: DRM lease protocol support

[Marius Vlad]

Hi Drew,

Thanks for taking the time to reboot the lease protocol!

On 6/27/19 11:36 PM, Simon Ser wrote:
> Hi,
> 
> Thanks for your work! Here is a first round of comments.
> 
> On Thursday, June 27, 2019 10:46 PM, Drew DeVault  wrote:
>> From: Marius Vlad 
>>
>> Simple protocol extension to manage DRM lease. Based on the work by Keith
>> Packard in [1], respectively [2].
>>
>> [1] 
>> https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e
>> [2] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f
>>
>> Signed-off-by: Marius Vlad 
>> Signed-off-by: Drew DeVault 
>> ---
>> This updates Marius's original patch series implementing DRM leasing for
>> Wayland. This cleans up the XML style, reworks resource lifetimes, adds
>> a little link to xdg-output, and a few other changes.
>>
>> A server-side implementation of this protocol is under development and
>> available here:
>>
>> https://github.com/swaywm/wlroots/pull/1730
>>
>> I've also rigged up Keith Packard's kmscube fork to support leasing from
>> Wayland instead of X:
>>
>> https://git.sr.ht/~sircmpwn/kmscube
>>
>> Run `./kmscube -l` to test it. While doing the research for this
>> protocol there was also some discussions in wlroots which may be
>> insightful:
>>
>> https://github.com/swaywm/wlroots/issues/1723
>>
>> Background:
>>
>> DRM leasing is a feature which allows the DRM master to "lease" a subset
>> of its DRM resources to another DRM master via drmModeCreateLease, which
>> returns a file descriptor for the new DRM master. We use this protocol
>> to negotiate the terms of the lease and transfer this file descriptor to
>> clients.
>>
>> In less DRM-specific terms: this protocol allows Wayland compositors to
>> give over their GPU resources (like displays) to a Wayland client to
>> exclusively control.
>>
>> The primary use-case for this is Virtual Reality headsets, which via the
>> non-desktop DRM property are generally not used as desktop displays by
>> Wayland compositors, and for latency reasons (among others) are most
>> useful to games et al if they have direct control over the DRM resources
>> associated with it. Basically, these are peripherals which are of no use
>> to the compositor and may be of use to a client, but since they are tied
>> up in DRM we need to use DRM leasing to get them into client's hands.
> 
> Maybe some of this can be integrated in the commit message.
> 
>> Previously there were some musings about the security considerations.
>> This version of the protocol allows the compositor to consider the lease
>> request in its own time, perhaps presenting the user with a dialog to
>> consent to the lease. Additionally, leased connectors can be added and
>> removed at the compositor's whim, and race conditions have been
>> considered to avoid disagreement between the client and compositor as to
>> which connectors are available for lease - the compositor being the
>> ultimate authority.
> 
> We still need a way to identify the client. See
> https://gitlab.freedesktop.org/wayland/weston/issues/206
> 
>>
>> In the coming weeks I intend to work on patches for Vulkan and Xwayland
>> adding support for this protocol, respectively to allow Vulkan clients
>> to utilize DRM leasing on Wayland and to allow X11 clients utilizing the
>> xrandr lease request[0] to fulfill their leases through Xwayland.
>>
>> https://gitlab.freedesktop.org/xorg/proto/xcbproto/blob/master/src/randr.xml#L909-938
>>
>>  Makefile.am  |   1 +
>>  unstable/drm-lease/README|   4 +
>>  unstable/drm-lease/drm-lease-unstable-v1.xml | 203 +++
>>  3 files changed, 208 insertions(+)
>>  create mode 100644 unstable/drm-lease/README
>>  create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 345ae6a..d9fff89 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -4,6 +4,7 @@ unstable_protocols = 
>> \
>>  unstable/pointer-gestures/pointer-gestures-unstable-v1.xml  
>> \
>>  unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
>> \
>>  unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
>> \
>> +    unstable/drm-lease/drm-lease-unstable-v1.x

Re: [PATCH] Allow to specify wayland-protocols datadir

[Marius Vlad]

On Fri, Jan 18, 2019 at 11:53:07AM +0200, Pekka Paalanen wrote:
> On Tue, 12 Dec 2017 23:10:18 +0200
> Marius Vlad  wrote:
> 
> > This is particularly useful when cross-compiling and we need to specify a 
> > custom
> > datadir path for wayland-protocols. Cross-compilation toolchain is usually
> > immutable, and in this way we can modify wayland-protocols independently 
> > from
> > what the toolchain provides.
> > 
> > Signed-off-by: Marius Vlad 
> > ---
> >  configure.ac | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/configure.ac b/configure.ac
> > index d1b5f47..11ebc21 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -213,7 +213,13 @@ PKG_CHECK_MODULES(COMPOSITOR, [$COMPOSITOR_MODULES])
> >  
> >  PKG_CHECK_MODULES(WAYLAND_PROTOCOLS, [wayland-protocols >= 1.8],
> >   [ac_wayland_protocols_pkgdatadir=`$PKG_CONFIG 
> > --variable=pkgdatadir wayland-protocols`])
> > -AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, $ac_wayland_protocols_pkgdatadir)
> > +AC_ARG_WITH(wayland-protocols-datadir-path,
> > +   AS_HELP_STRING([--with-wayland-protocols-datadir-path=PATH],
> > +   [Path to wayland-protocols]),
> > +   [WAYLAND_PROTOCOLS_DATADIR="$withval"],
> > +   
> > [WAYLAND_PROTOCOLS_DATADIR="$ac_wayland_protocols_pkgdatadir"])
> > +
> > +AC_SUBST([WAYLAND_PROTOCOLS_DATADIR])
> >  
> >  AC_ARG_ENABLE(wayland-compositor, [  --enable-wayland-compositor],,
> >   enable_wayland_compositor=yes)
> 
> Hi Marius,
Hi Pekka,
> 
> I noticed this patch did not land. Would we need something like this
> for Meson in Weston?

I get the feeling that people when cross-compiling don't really use
cross-compilers but instead resort to various way of faking other ARCH
systems. This includes the typical cross-deboostrap with
qemu-static-arm.

The above path tries to fix the issue of having to specify
PKG_CONFIG_WAYLAND_PROTOCOLS_PKGDATADIR to get wayland-protocols from
other directory that the regular (install) path. The problem is
exacerbated when using cross toolchains which modify PKG_CONFIG vars and
use other SYSROOT. Under yocto for instance I have to modify PKG_CONFIG
vars to make weston choose another datadir for wayland-protocols along
side exporting PKG_CONFIG_WAYLAND_PROTOCOLS_PKGDATADIR.

I might be wrong but I believe yocto itself deals with this by
maintaining some off the shelf patches.

I have in plan of writing a cross file for meson and testing various
cross-toolchains like OSELAS/yocto/linaro/debian. Think that something
equivalent will be needed as meson uses pkg-config as well, but I
haven't had time to go over it. Somehow this implies automated ways of
generating cross file(s) as to tackle various toolchain environments,
which to be honest autotools dealt a lot better that meson at
this point.
> 
> This seems to be a Weston patch, but the only thing hinting at that is
> the context in the diff.
> 
> 
> Thanks,
> pq




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

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

[Marius Vlad]

Simple protocol extension to manage DRM lease. Based on the work by Keith
Packard in [1], respectively [2].

[1] 
https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f

Changes since v4:
- send also information (gratuitously) about the connector once the client has 
it
a zwp_kms_lease_connector_v1 object (Philipp Zabel)
- use the destructor of zwp_kms_lease_v1 to revoke the lease,
and remove the zwp_kms_lease_request_v1::revoke request, as this
will no longer be necessary (Philipp Zabel)
- once the client obtains a zwp_kms_lease_v1 object, using the temporary
zwp_kms_lease_request_v1 object is no longer necessary so the client
can freely call its destructor (Philipp Zabel)
- polished the main commentary to reflect these changes and fixed some
minor typos (Philipp Zabel)
- removed 'revoked' event entirely as it adds complexity without adding
too much benefit.

Changes since v3:
- instead of advertising all leasable connectors at once, advertise each
connector for each leasable output.  Use an object to represent a
leasable connector and provide a request to add that leasable connector
when creating the lease (Philipp Zabel)
- add two events to handle add_connector request
- add some comments in manager interface to explain how the protocol
is designed to work

Changes since v2:
- advertise connectors when creating a lease request object (Pekka Paalanen)
- when revoking the lease use the lease object instead of lessee id (Pekka 
Paalanen)
- various grammar/spelling fixes (Pekka Paalanen)

Changes since v1:
- added manager: advertise lease capability and manage the lease (Daniel Stone)
- add request(s) for adding connector/crtc/plane to behave more like dmabuf 
(Daniel Stone)

Signed-off-by: Marius Vlad 
---

An implementation for this version can be found at
https://gitlab.freedesktop.org/marius.vlad0/weston/commits/drm-lease-advertise-each-connnector-object-fixes

 Makefile.am  |   1 +
 unstable/drm-lease/README|   4 +
 unstable/drm-lease/drm-lease-unstable-v1.xml | 226 +++
 3 files changed, 231 insertions(+)
 create mode 100644 unstable/drm-lease/README
 create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 6394e26..5d13dca 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4,6 +4,7 @@ unstable_protocols =
\
unstable/pointer-gestures/pointer-gestures-unstable-v1.xml  
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
+   unstable/drm-lease/drm-lease-unstable-v1.xml
\
unstable/text-input/text-input-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
diff --git a/unstable/drm-lease/README b/unstable/drm-lease/README
new file mode 100644
index 000..a25600c
--- /dev/null
+++ b/unstable/drm-lease/README
@@ -0,0 +1,4 @@
+Linux DRM lease
+
+Maintainers:
+Marius Vlad 
diff --git a/unstable/drm-lease/drm-lease-unstable-v1.xml 
b/unstable/drm-lease/drm-lease-unstable-v1.xml
new file mode 100644
index 000..9fcaea5
--- /dev/null
+++ b/unstable/drm-lease/drm-lease-unstable-v1.xml
@@ -0,0 +1,226 @@
+
+
+
+
+Copyright 2018 NXP
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+
+
+  
+
+  This interface makes use of DRM lease written by Keith Packard.
+
+  A DRM master can create another DRM master and ``lease'' resources it has

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

[Marius Vlad]

Simple protocol extension to manage DRM lease. Based on the work by Keith
Packard in [1], respectively [2].

[1] 
https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f

Changes since v3:
- instead of advertising all leasable connectors at once, advertise each
connector for each leasable output.  Use an object to represent a
leasable connector and provide a request to add that leasable connector
when creating the lease (Philipp Zabel)
- add two events to handle add_connector request
- add some comments in the manager interface to explain how the protocol
can/should be used

Changes since v2:
- advertise connectors when creating a lease request object (Pekka Paalanen)
- when revoking the lease use the lease object instead of lessee id (Pekka 
Paalanen)
- various grammar/spelling fixes (Pekka Paalanen)

Changes since v1:
- added manager: advertise lease capability and manage the lease (Daniel Stone)
- add request(s) for adding connector/crtc/plane to behave more like dmabuf 
(Daniel Stone)

Signed-off-by: Marius Vlad 
---
A (rather incomplete) implementation for this version can be found at
https://gitlab.freedesktop.org/marius.vlad0/weston/tree/drm-lease-advertise-each-connnector-object

One interesting question is how to handle the situation when the client
deliberately, or not, holds the lease indefinitely. This has multiple
ramification like what happens when the client un-expectingly dies and doesn't
revoking the lease, or when hot-plugging the connector and weston tries to get
a hold of a connector previously leased? It could be there might be other
situations where the compositor will need to revoke the lease. 

In the implementation we could deny the compositor to get a hold of the
connector when hot-plugging that output, if that's desirable, and presumably
establish a way to detect periodically if the lease is still in use.

Alternatively, shouldn't we use something like a ping/pong approach in which
the client (in rendering part), sends periodically an alive signal?


 Makefile.am  |   1 +
 unstable/drm-lease/README|   4 +
 unstable/drm-lease/drm-lease-unstable-v1.xml | 244 +++
 3 files changed, 249 insertions(+)
 create mode 100644 unstable/drm-lease/README
 create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 6394e26..5d13dca 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4,6 +4,7 @@ unstable_protocols =
\
unstable/pointer-gestures/pointer-gestures-unstable-v1.xml  
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
+   unstable/drm-lease/drm-lease-unstable-v1.xml
\
unstable/text-input/text-input-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
diff --git a/unstable/drm-lease/README b/unstable/drm-lease/README
new file mode 100644
index 000..a25600c
--- /dev/null
+++ b/unstable/drm-lease/README
@@ -0,0 +1,4 @@
+Linux DRM lease
+
+Maintainers:
+Marius Vlad 
diff --git a/unstable/drm-lease/drm-lease-unstable-v1.xml 
b/unstable/drm-lease/drm-lease-unstable-v1.xml
new file mode 100644
index 000..40eedb4
--- /dev/null
+++ b/unstable/drm-lease/drm-lease-unstable-v1.xml
@@ -0,0 +1,244 @@
+
+
+
+
+Copyright 2018 NXP
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+
+
+  
+
+  This interface makes use 

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

[Marius Vlad]

Simple protocol extension to manage DRM lease. Based on the work by Keith
Packard in [1], respectively [2].

[1] 
https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f

Signed-off-by: Marius Vlad 

Changes since v2:
- advertise connector names when creating a lease request object (Pekka 
Paalanen)
- when revoking the lease use the lease object instead of lessee id (Pekka 
Paalanen)
- various grammar/spelling fixes (Pekka Paalanen)

Changes since v1:
- added manager: advertise lease capability and manage the lease (Daniel Stone)
- add request(s) for adding connector/crtc/plane to behave more like dmabuf 
(Daniel Stone)
---
Some caveats while at it. This is just in RFC form adapted from the comments
I've  mostly got from Pekka Paalanen. It most certainly doesn't address all the 
issues
brought up: like multi-node card environments/system, doing a TEST_ONLY
commit before giving out a lease, or takes hot-plugging into consideration. 
As I was side-tracked to other things and
being on hiatus for a while, I wanted first to get some impressions first if
indeed this is the right approach and do some incremental updates afterwards.

The are some issues which I'd like to point out from the beginning, which
require some further comments. In no particular order:

I've found that I can't pass a wl_array as a way to advertise various
information to the client. (wl_array works fine with integers not with
allocated data). It would probably be better to advertise also
monitor name, other EDID info or available modes, but at the moment I only 
join-split a delimiter between connector names and send it out as a string.  
While it is ugly I'm not aware of a way to send this information back to the
client in the form of a list. 
The client is aware before hand of this delimiter and has the number of entries:
can easily choose or pick one of the connectors. It could be that there are
some other ways this can be achieved, I welcome any kind of feedback here.

Secondly, when doing a modeset, the client requires a valid mode
(drmModeModeInfo).  I'm currently unsure how to pass this back to the client.
The obvious type="object" interface="drmModeModeInfo" fails to link and instead
I rely on the fact that a) the client can retrieve IDs from the lease using
lease API (drmModeGetLease()) which gives a connector id -- 
or alternately can also use a wl_array to pass that,
and b) the client can use the leased fd to iterate over connectors.
Matching those two would allow to get a valid
drmModeModeInfo object to pass it when modesetting (for more info
see the client implementation provided at the end).
Question is, is this an acceptable way of doing it? Do note that this
can only be "used" after the lease has been created.

A server/client implementation to match this protocol 
can be found at 
https://gitlab.freedesktop.org/marius.vlad0/weston/commits/new-drm-lease

 Makefile.am  |   1 +
 unstable/drm-lease/README|   4 +
 unstable/drm-lease/drm-lease-unstable-v1.xml | 173 +++
 3 files changed, 178 insertions(+)
 create mode 100644 unstable/drm-lease/README
 create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 6394e26..5d13dca 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4,6 +4,7 @@ unstable_protocols =
\
unstable/pointer-gestures/pointer-gestures-unstable-v1.xml  
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
+   unstable/drm-lease/drm-lease-unstable-v1.xml
\
unstable/text-input/text-input-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v3.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
diff --git a/unstable/drm-lease/README b/unstable/drm-lease/README
new file mode 100644
index 000..a25600c
--- /dev/null
+++ b/unstable/drm-lease/README
@@ -0,0 +1,4 @@
+Linux DRM lease
+
+Maintainers:
+Marius Vlad 
diff --git a/unstable/drm-lease/drm-lease-unstable-v1.xml 
b/unstable/drm-lease/drm-lease-unstable-v1.xml
new file mode 100644
index 000..6cb3c0a
--- /dev/null
+++ b/unstable/drm-lease/drm-lease-unstable-v1.xml
@@ -0,0 +1,173 @@
+
+
+
+
+Copyright 2018 NXP
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, 

[PATCH weston 2/2 v5] clients/simple-egl-lease: A demo client for DRM leases

[Marius Vlad]

Heavily inspired by kmscube and simple-egl. Uses legacy page-flipping and
triangle shaders from simple-egl.

Signed-off-by: Marius Vlad 
---
 Makefile.am|  11 +
 clients/simple-egl-lease.c | 887 +
 clients/simple-egl-lease.h |  99 +
 configure.ac   |  17 +
 4 files changed, 1014 insertions(+)
 create mode 100644 clients/simple-egl-lease.c
 create mode 100644 clients/simple-egl-lease.h

diff --git a/Makefile.am b/Makefile.am
index 00a49d9..abde6f2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -649,6 +649,17 @@ weston_simple_dmabuf_v4l_CFLAGS = $(AM_CFLAGS) 
$(SIMPLE_DMABUF_V4L_CLIENT_CFLAGS
 weston_simple_dmabuf_v4l_LDADD = $(SIMPLE_DMABUF_V4L_CLIENT_LIBS) libshared.la
 endif
 
+if BUILD_SIMPLE_EGL_LEASE_CLIENTS
+demo_clients += weston-simple-egl-lease
+weston_simple_egl_lease_SOURCES = clients/simple-egl-lease.c
+nodist_weston_simple_egl_lease_SOURCES = 
protocol/drm-lease-unstable-v1-protocol.c \
+   protocol/drm-lease-unstable-v1-client-protocol.h
+weston_simple_egl_lease_CFLAGS = $(AM_CFLAGS) 
$(SIMPLE_EGL_LEASE_CLIENT_CFLAGS) \
+$(LIBDRM_CFLAGS)
+weston_simple_egl_lease_LDADD = $(SIMPLE_EGL_LEASE_CLIENT_LIBS) $(LIBDRM_LIBS) 
\
+   $(GBM_LIBS) -lm
+endif
+
 noinst_LTLIBRARIES += libtoytoolkit.la
 
 libtoytoolkit_la_SOURCES = \
diff --git a/clients/simple-egl-lease.c b/clients/simple-egl-lease.c
new file mode 100644
index 000..8922e57
--- /dev/null
+++ b/clients/simple-egl-lease.c
@@ -0,0 +1,887 @@
+/*
+ * Copyright 2018 NXP
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Adapted from kmscube and simple-egl. No atomic support atm.
+ *
+ */
+
+#include "config.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include "drm-lease-unstable-v1-client-protocol.h"
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include "simple-egl-lease.h"
+
+static volatile uint8_t sig_recv = 0;
+
+static const GLfloat verts[3][2] = {
+   { -0.5, -0.5 },
+   {  0.5, -0.5 },
+   {  0,0.5 }
+};
+
+static const GLfloat colors[3][3] = {
+   { 1, 0, 0 },
+   { 0, 1, 0 },
+   { 0, 0, 1 }
+};
+
+GLfloat rotation[4][4] = {
+   { 1, 0, 0, 0 },
+   { 0, 1, 0, 0 },
+   { 0, 0, 1, 0 },
+   { 0, 0, 0, 1 }
+};
+
+static const char *vertex_shader_source =
+   "uniform mat4 rotation;\n"
+   "attribute vec4 pos;\n"
+   "attribute vec4 color;\n"
+   "varying vec4 v_color;\n"
+   "void main() {\n"
+   "  gl_Position = rotation * pos;\n"
+   "  v_color = color;\n"
+   "}\n";
+
+static const char *fragment_shader_source =
+   "precision mediump float;\n"
+   "varying vec4 v_color;\n"
+   "void main() {\n"
+   "  gl_FragColor = v_color;\n"
+   "}\n";
+
+static struct gbm *
+init_gbm(int drm_fd, int w, int h)
+{
+   struct gbm *gbm = calloc(1, sizeof(*gbm));
+
+   gbm->dev = gbm_create_device(drm_fd);
+
+   gbm->surface = gbm_surface_create(gbm->dev, w, h, GBM_FORMAT_XRGB,
+ GBM_BO_USE_SCANOUT | 
GBM_BO_USE_RENDERING);
+   if (!gbm->surface) {
+   printf("failed to create gbm surface\n");
+   return NULL;
+   }
+
+   gbm->width = w;
+   gbm->height = h;
+
+   return gbm;
+}
+
+static int
+init_egl(struct egl *egl, const struct gbm *gbm)
+{
+   EGLint major, minor, n;
+
+   static const EGLint context_attribs[] = {
+  

[PATCH weston 0/2 v5] DRM lease support

[Marius Vlad]

Functional no change since last version, just rebased to take into account
clone series.

Patch series that adds support for DRM leases.

DRM leases is a method developed by Keith Packard to allow other application 
manage the output of a display/VR, while a DRM master is already owning
the outputs resources. A more thorough explanation and terminology can
be found at [1]. libdrm [2] and kernel [3] have already gained support.

Protocol support can be found at [4].

Initially this was a single patch but decided to split into series to
accommodate a demo client as well.

Changes since v4:
- rebased in order to get connector id from from drm_head

Changes since v3:
- rename lease with leasable to avoid confusion (Philipp Zabel)
- added client protocol headers / protocol to BUILD_SOURCES otherwise the
client example can't be built due to missing client headers

Changes since v2:
- rebased as drm_output_disable() has been changed due to atomic changes
- deferring the lease when the output can't be disabled due to a pending 
flip
- client blocks until it receives a 'created'/'failed' event when
deferring the lease.
- fix a potential NULL pointer if failing to get an encoder in the client
- provide correct link to protocol
- use lessee_id instead of lease_id as per libdrm/kernel terminology

Changes since v1:
- accommodate changes due to protocol changes
- use enable/disabled for the output instead of destroy/update_outputs (Daniel 
Stone)
- split into a series, added a client example
- forcing a repaint when giving the lease and not doing a modeset if the output
has been leased avoids blank switching between the lesor and lessee

[1] https://keithp.com/blogs/DRM-lease/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f
[3] 
https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e
[4] 
https://lists.freedesktop.org/archives/wayland-devel/2018-February/036947.html

Marius Vlad (2):
  compositor-drm: Add support for DRM lease
  clients/simple-egl-lease: A demo client for DRM leases

 Makefile.am|  19 +-
 clients/simple-egl-lease.c | 887 +
 clients/simple-egl-lease.h |  99 +
 compositor/main.c  |   6 +
 configure.ac   |  21 ++
 libweston/compositor-drm.c | 279 +-
 libweston/compositor.c |   1 +
 libweston/compositor.h |   1 +
 8 files changed, 1310 insertions(+), 3 deletions(-)
 create mode 100644 clients/simple-egl-lease.c
 create mode 100644 clients/simple-egl-lease.h

-- 
2.9.3

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

[PATCH weston 1/2 v5] compositor-drm: Add support for DRM lease

[Marius Vlad]

Signed-off-by: Marius Vlad 
---
 Makefile.am|   8 +-
 compositor/main.c  |   6 +
 configure.ac   |   4 +
 libweston/compositor-drm.c | 279 -
 libweston/compositor.c |   1 +
 libweston/compositor.h |   1 +
 6 files changed, 296 insertions(+), 3 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 69ca6cb..00a49d9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -168,7 +168,9 @@ nodist_libweston_@LIBWESTON_MAJOR@_la_SOURCES = 
\
protocol/pointer-constraints-unstable-v1-protocol.c \
protocol/pointer-constraints-unstable-v1-server-protocol.h  \
protocol/input-timestamps-unstable-v1-protocol.c\
-   protocol/input-timestamps-unstable-v1-server-protocol.h
+   protocol/input-timestamps-unstable-v1-server-protocol.h \
+   protocol/drm-lease-unstable-v1-protocol.c   \
+   protocol/drm-lease-unstable-v1-server-protocol.h
 
 BUILT_SOURCES += $(nodist_libweston_@LIBWESTON_MAJOR@_la_SOURCES)
 
@@ -889,7 +891,9 @@ BUILT_SOURCES +=\
protocol/linux-dmabuf-unstable-v1-protocol.c\
protocol/linux-dmabuf-unstable-v1-client-protocol.h \
protocol/input-timestamps-unstable-v1-protocol.c\
-   protocol/input-timestamps-unstable-v1-client-protocol.h
+   protocol/input-timestamps-unstable-v1-client-protocol.h \
+   protocol/drm-lease-unstable-v1-protocol.c   \
+   protocol/drm-lease-unstable-v1-client-protocol.h
 
 westondatadir = $(datadir)/weston
 dist_westondata_DATA = \
diff --git a/compositor/main.c b/compositor/main.c
index 1092204..8fda259 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -1234,6 +1234,7 @@ drm_backend_output_configure(struct weston_output *output)
char *modeline = NULL;
char *gbm_format = NULL;
char *seat = NULL;
+   char *lease = NULL;
 
if (!api) {
weston_log("Cannot use weston_drm_output_api.\n");
@@ -1276,6 +1277,11 @@ drm_backend_output_configure(struct weston_output 
*output)
api->set_seat(output, seat);
free(seat);
 
+   weston_config_section_get_string(section, "lease", , "off");
+   if (!strncmp(lease, "on", 2))
+   output->leasable = true;
+   free(lease);
+
return 0;
 }
 
diff --git a/configure.ac b/configure.ac
index da3f734..a81b137 100644
--- a/configure.ac
+++ b/configure.ac
@@ -212,6 +212,10 @@ if test x$enable_drm_compositor = xyes; then
   PKG_CHECK_MODULES(DRM_COMPOSITOR_GBM, [gbm >= 10.2],
[AC_DEFINE([HAVE_GBM_FD_IMPORT], 1, [gbm supports dmabuf 
import])],
[AC_MSG_WARN([gbm does not support dmabuf import, will omit 
that capability])])
+  PKG_CHECK_MODULES(DRM_LEASE, [libdrm >= 2.4.89],
+   [AC_DEFINE([HAVE_DRM_LEASE], 1, [libdrm support lease 
capability])],
+   [AC_MSG_WARN([libdrm doesn't have leases support, will omit 
that capability])])
+
 fi
 
 
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 8b1ea66..4b7b470 100644
--- a/libweston/compositor-drm.c
+++ b/libweston/compositor-drm.c
@@ -64,6 +64,7 @@
 #include "presentation-time-server-protocol.h"
 #include "linux-dmabuf.h"
 #include "linux-dmabuf-unstable-v1-server-protocol.h"
+#include "drm-lease-unstable-v1-server-protocol.h"
 
 #ifndef DRM_CAP_TIMESTAMP_MONOTONIC
 #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
@@ -273,6 +274,21 @@ struct drm_backend {
uint32_t pageflip_timeout;
 
bool shutting_down;
+   struct wl_list leases;
+};
+
+struct lease {
+   int leased_fd;
+   uint32_t lessee_id;
+
+   int nobjects;
+   int tnobjects;
+   uint32_t *objects;
+
+   struct drm_output *leased_output;
+   struct wl_resource *lease_resource;
+   struct drm_backend *drm_backend;
+   struct wl_list link;
 };
 
 struct drm_mode {
@@ -436,6 +452,7 @@ struct drm_output {
int destroy_pending;
int disable_pending;
int dpms_off_pending;
+   int lease_pending;
 
struct drm_fb *gbm_cursor_fb[2];
struct drm_plane *cursor_plane;
@@ -463,6 +480,7 @@ struct drm_output {
struct wl_listener recorder_frame_listener;
 
struct wl_event_source *pageflip_timer;
+   struct lease *lease;
 };
 
 static struct gl_renderer_interface *gl_renderer;
@@ -1392,6 +1410,38 @@ drm_pending_state_get_output(struct drm_pending_state 
*pending_state,
 
 static int drm_pending_state_apply_sync(struct drm_pending_state *state);
 
+#ifdef HAVE_DRM_LEASE
+static void
+drm_lease_clear_objects(struct lease *lease)
+{
+   memset(lease->objects, 0, sizeof(uint32_t) * lease->tnobjects)

[PATCH weston 0/2 v4] DRM lease support

[Marius Vlad]

Patch series that adds support for DRM leases.

DRM leases is a method developed by Keith Packard to allow other application 
manage the output of a display/VR, while a DRM master is already owning
the outputs resources. A more thorough explanation and terminology can
be found at [1]. libdrm [2] and kernel [3] have already gained support.

Protocol support can be found at [4].

Initially this was a single patch but decided to split into series to
accommodate a demo client as well.

Changes since v3:
- rename lease with leasable to avoid confusion (Philipp Zabel)
- added client protocol headers / protocol to BUILD_SOURCES otherwise the
client example can't be built due to missing client headers

Changes since v2:
- rebased as drm_output_disable() has been changed due to atomic changes
- deferring the lease when the output can't be disabled due to a pending 
flip
- client blocks until it receives a 'created'/'failed' event when
deferring the lease.
- fix a potential NULL pointer if failing to get an encoder in the client
- provide correct link to protocol
- use lessee_id instead of lease_id as per libdrm/kernel terminology

Changes since v1:
- accommodate changes due to protocol changes
- use enable/disabled for the output instead of destroy/update_outputs (Daniel 
Stone)
- split into a series, added a client example
- forcing a repaint when giving the lease and not doing a modeset if the output
has been leased avoids blank switching between the lesor and lessee

[1] https://keithp.com/blogs/DRM-lease/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f
[3] 
https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e
[4] 
https://lists.freedesktop.org/archives/wayland-devel/2018-February/036947.html


Marius Vlad (2):
  compositor-drm: Add support for DRM lease
  clients/simple-egl-lease: A demo client for DRM leases

 Makefile.am|  15 +
 clients/simple-egl-lease.c | 887 +
 clients/simple-egl-lease.h |  99 +
 compositor/main.c  |  11 +
 configure.ac   |  21 ++
 libweston/compositor-drm.c | 272 ++
 libweston/compositor.c |   1 +
 libweston/compositor.h |   2 +
 8 files changed, 1308 insertions(+)
 create mode 100644 clients/simple-egl-lease.c
 create mode 100644 clients/simple-egl-lease.h

-- 
2.9.3

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

[PATCH weston 1/2 v4] compositor-drm: Add support for DRM lease

[Marius Vlad]

Signed-off-by: Marius Vlad <marius-cristian.v...@nxp.com>
---
 Makefile.am|   4 +
 compositor/main.c  |  11 ++
 configure.ac   |   4 +
 libweston/compositor-drm.c | 272 +
 libweston/compositor.c |   1 +
 libweston/compositor.h |   2 +
 6 files changed, 294 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index 69ca6cb..9c53a6b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -163,6 +163,8 @@ nodist_libweston_@LIBWESTON_MAJOR@_la_SOURCES = 
\
protocol/viewporter-server-protocol.h   \
protocol/linux-dmabuf-unstable-v1-protocol.c\
protocol/linux-dmabuf-unstable-v1-server-protocol.h \
+   protocol/drm-lease-unstable-v1-protocol.c   \
+   protocol/drm-lease-unstable-v1-server-protocol.h\
protocol/relative-pointer-unstable-v1-protocol.c\
protocol/relative-pointer-unstable-v1-server-protocol.h \
protocol/pointer-constraints-unstable-v1-protocol.c \
@@ -888,6 +890,8 @@ BUILT_SOURCES +=\
protocol/ivi-application-client-protocol.h  \
protocol/linux-dmabuf-unstable-v1-protocol.c\
protocol/linux-dmabuf-unstable-v1-client-protocol.h \
+   protocol/drm-lease-unstable-v1-protocol.c   \
+   protocol/drm-lease-unstable-v1-client-protocol.h\
protocol/input-timestamps-unstable-v1-protocol.c\
protocol/input-timestamps-unstable-v1-client-protocol.h
 
diff --git a/compositor/main.c b/compositor/main.c
index 1e82788..5ea15fc 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -1093,6 +1093,17 @@ drm_backend_output_configure(struct wl_listener 
*listener, void *data)
api->set_seat(output, seat);
free(seat);
 
+   char *lease;
+   weston_config_section_get_string(section, "lease", , "off");
+   if (!strncmp(lease, "on", 2)) {
+   output->leasable = true;
+#ifdef DEBUG
+   weston_log("Enabling lease on output %s\n", output->name);
+#endif
+   }
+   free(lease);
+
+
weston_output_enable(output);
 }
 
diff --git a/configure.ac b/configure.ac
index 1609ace..738f4a4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -212,6 +212,10 @@ if test x$enable_drm_compositor = xyes; then
   PKG_CHECK_MODULES(DRM_COMPOSITOR_GBM, [gbm >= 10.2],
[AC_DEFINE([HAVE_GBM_FD_IMPORT], 1, [gbm supports dmabuf 
import])],
[AC_MSG_WARN([gbm does not support dmabuf import, will omit 
that capability])])
+  PKG_CHECK_MODULES(DRM_LEASE, [libdrm >= 2.4.89],
+   [AC_DEFINE([HAVE_DRM_LEASE], 1, [libdrm support lease 
capability])],
+   [AC_MSG_WARN([libdrm doesn't have leases support, will omit 
that capability])])
+
 fi
 
 
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 81ca67d..dc2d37f 100644
--- a/libweston/compositor-drm.c
+++ b/libweston/compositor-drm.c
@@ -62,6 +62,7 @@
 #include "presentation-time-server-protocol.h"
 #include "linux-dmabuf.h"
 #include "linux-dmabuf-unstable-v1-server-protocol.h"
+#include "drm-lease-unstable-v1-server-protocol.h"
 
 #ifndef DRM_CAP_TIMESTAMP_MONOTONIC
 #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
@@ -269,6 +270,21 @@ struct drm_backend {
uint32_t pageflip_timeout;
 
bool shutting_down;
+   struct wl_list leases;
+};
+
+struct lease {
+   int leased_fd;
+   uint32_t lessee_id;
+
+   int nobjects;
+   int tnobjects;
+   uint32_t *objects;
+
+   struct drm_output *leased_output;
+   struct wl_resource *lease_resource;
+   struct drm_backend *drm_backend;
+   struct wl_list link;
 };
 
 struct drm_mode {
@@ -422,6 +438,7 @@ struct drm_output {
int destroy_pending;
int disable_pending;
int dpms_off_pending;
+   int lease_pending;
 
struct drm_fb *gbm_cursor_fb[2];
struct drm_plane *cursor_plane;
@@ -449,6 +466,8 @@ struct drm_output {
struct wl_listener recorder_frame_listener;
 
struct wl_event_source *pageflip_timer;
+
+   struct lease *lease;
 };
 
 static struct gl_renderer_interface *gl_renderer;
@@ -1383,6 +1402,36 @@ drm_pending_state_get_output(struct drm_pending_state 
*pending_state,
 
 static int drm_pending_state_apply_sync(struct drm_pending_state *state);
 
+#ifdef HAVE_DRM_LEASE
+static void
+drm_lease_clear_objects(struct lease *lease)
+{
+   memset(lease->objects, 0, sizeof(uint32_t) * lease->tnobjects);
+   lease->tnobjects = 0;
+}
+
+static void
+drm_output_send_lease(struct drm_output *output)
+{
+   struct lease *lease = output->lease;
+   struct wl_resource *resource = lease->lease_reso

[PATCH weston 2/2 v4] clients/simple-egl-lease: A demo client for DRM leases

[Marius Vlad]

Heavily inspired by kmscube and simple-egl. Uses legacy page-flipping and
triangle shaders from simple-egl.

Signed-off-by: Marius Vlad <marius-cristian.v...@nxp.com>
---
 Makefile.am|  11 +
 clients/simple-egl-lease.c | 887 +
 clients/simple-egl-lease.h |  99 +
 configure.ac   |  17 +
 4 files changed, 1014 insertions(+)
 create mode 100644 clients/simple-egl-lease.c
 create mode 100644 clients/simple-egl-lease.h

diff --git a/Makefile.am b/Makefile.am
index 9c53a6b..d099b12 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -649,6 +649,17 @@ weston_simple_dmabuf_v4l_CFLAGS = $(AM_CFLAGS) 
$(SIMPLE_DMABUF_V4L_CLIENT_CFLAGS
 weston_simple_dmabuf_v4l_LDADD = $(SIMPLE_DMABUF_V4L_CLIENT_LIBS) libshared.la
 endif
 
+if BUILD_SIMPLE_EGL_LEASE_CLIENTS
+demo_clients += weston-simple-egl-lease
+weston_simple_egl_lease_SOURCES = clients/simple-egl-lease.c
+nodist_weston_simple_egl_lease_SOURCES = 
protocol/drm-lease-unstable-v1-protocol.c \
+   protocol/drm-lease-unstable-v1-client-protocol.h
+weston_simple_egl_lease_CFLAGS = $(AM_CFLAGS) 
$(SIMPLE_EGL_LEASE_CLIENT_CFLAGS) \
+$(LIBDRM_CFLAGS)
+weston_simple_egl_lease_LDADD = $(SIMPLE_EGL_LEASE_CLIENT_LIBS) $(LIBDRM_LIBS) 
\
+   $(GBM_LIBS) -lm
+endif
+
 noinst_LTLIBRARIES += libtoytoolkit.la
 
 libtoytoolkit_la_SOURCES = \
diff --git a/clients/simple-egl-lease.c b/clients/simple-egl-lease.c
new file mode 100644
index 000..8922e57
--- /dev/null
+++ b/clients/simple-egl-lease.c
@@ -0,0 +1,887 @@
+/*
+ * Copyright 2018 NXP
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Adapted from kmscube and simple-egl. No atomic support atm.
+ *
+ */
+
+#include "config.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include "drm-lease-unstable-v1-client-protocol.h"
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include "simple-egl-lease.h"
+
+static volatile uint8_t sig_recv = 0;
+
+static const GLfloat verts[3][2] = {
+   { -0.5, -0.5 },
+   {  0.5, -0.5 },
+   {  0,0.5 }
+};
+
+static const GLfloat colors[3][3] = {
+   { 1, 0, 0 },
+   { 0, 1, 0 },
+   { 0, 0, 1 }
+};
+
+GLfloat rotation[4][4] = {
+   { 1, 0, 0, 0 },
+   { 0, 1, 0, 0 },
+   { 0, 0, 1, 0 },
+   { 0, 0, 0, 1 }
+};
+
+static const char *vertex_shader_source =
+   "uniform mat4 rotation;\n"
+   "attribute vec4 pos;\n"
+   "attribute vec4 color;\n"
+   "varying vec4 v_color;\n"
+   "void main() {\n"
+   "  gl_Position = rotation * pos;\n"
+   "  v_color = color;\n"
+   "}\n";
+
+static const char *fragment_shader_source =
+   "precision mediump float;\n"
+   "varying vec4 v_color;\n"
+   "void main() {\n"
+   "  gl_FragColor = v_color;\n"
+   "}\n";
+
+static struct gbm *
+init_gbm(int drm_fd, int w, int h)
+{
+   struct gbm *gbm = calloc(1, sizeof(*gbm));
+
+   gbm->dev = gbm_create_device(drm_fd);
+
+   gbm->surface = gbm_surface_create(gbm->dev, w, h, GBM_FORMAT_XRGB,
+ GBM_BO_USE_SCANOUT | 
GBM_BO_USE_RENDERING);
+   if (!gbm->surface) {
+   printf("failed to create gbm surface\n");
+   return NULL;
+   }
+
+   gbm->width = w;
+   gbm->height = h;
+
+   return gbm;
+}
+
+static int
+init_egl(struct egl *egl, const struct gbm *gbm)
+{
+   EGLint major, minor, n;
+
+   static con

[PATCH weston] libweston/compositor-drm: Reset repaint scheduled status when setting DPMS level to off

[Marius Vlad]

Otherwise when setting dpms level DPMS_ON, weston_output_schedule_repaint()
will bail out early and never get a chance to wake up the output.

Arguably this could also be done in drm_set_dpms() when setting dpms_off_pending
but I figure it better to do it when deferred.

Signed-off-by: Marius Vlad <marius-cristian.v...@nxp.com>
CC: Daniel Stone <dan...@fooishbar.org>
CC: Pekka Paalanen <ppaala...@gmail.com>
---
 libweston/compositor-drm.c | 6 ++
 libweston/compositor.c | 2 +-
 libweston/compositor.h | 2 ++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 9594425..a53086e 100644
--- a/libweston/compositor-drm.c
+++ b/libweston/compositor-drm.c
@@ -1439,6 +1439,12 @@ drm_output_update_complete(struct drm_output *output, 
uint32_t flags,
} else if (output->dpms_off_pending) {
struct drm_pending_state *pending = drm_pending_state_alloc(b);
output->dpms_off_pending = 0;
+   /* reset repaint status so that weston_output_schedule_repaint()
+* will start the repaint_loop when DPMS level is ON */
+#ifdef DEBUG
+   weston_log("Reseting repaint status for output %s\n", 
output->base.name);
+#endif
+   weston_output_schedule_repaint_reset(>base);
drm_output_get_disable_state(pending, output);
drm_pending_state_apply_sync(pending);
return;
diff --git a/libweston/compositor.c b/libweston/compositor.c
index 274a22d..79c8d21 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -2360,7 +2360,7 @@ weston_output_repaint(struct weston_output *output, void 
*repaint_data)
return r;
 }
 
-static void
+WL_EXPORT void
 weston_output_schedule_repaint_reset(struct weston_output *output)
 {
output->repaint_status = REPAINT_NOT_SCHEDULED;
diff --git a/libweston/compositor.h b/libweston/compositor.h
index 010f1fa..afd49f5 100644
--- a/libweston/compositor.h
+++ b/libweston/compositor.h
@@ -1461,6 +1461,8 @@ weston_output_finish_frame(struct weston_output *output,
 void
 weston_output_schedule_repaint(struct weston_output *output);
 void
+weston_output_schedule_repaint_reset(struct weston_output *output);
+void
 weston_output_damage(struct weston_output *output);
 void
 weston_compositor_schedule_repaint(struct weston_compositor *compositor);
-- 
2.9.3

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

[PATCH weston 1/2 v3] compositor-drm: Add support for DRM lease

[Marius Vlad]

Signed-off-by: Marius Vlad <marius-cristian.v...@nxp.com>
---
 Makefile.am|   2 +
 compositor/main.c  |   9 ++
 configure.ac   |   4 +
 libweston/compositor-drm.c | 272 +
 libweston/compositor.c |   1 +
 libweston/compositor.h |   2 +
 6 files changed, 290 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index b5c29c0..439fa73 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -163,6 +163,8 @@ nodist_libweston_@LIBWESTON_MAJOR@_la_SOURCES = 
\
protocol/viewporter-server-protocol.h   \
protocol/linux-dmabuf-unstable-v1-protocol.c\
protocol/linux-dmabuf-unstable-v1-server-protocol.h \
+   protocol/drm-lease-unstable-v1-protocol.c   \
+   protocol/drm-lease-unstable-v1-server-protocol.h\
protocol/relative-pointer-unstable-v1-protocol.c\
protocol/relative-pointer-unstable-v1-server-protocol.h \
protocol/pointer-constraints-unstable-v1-protocol.c \
diff --git a/compositor/main.c b/compositor/main.c
index 18810f2..020553f 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -1092,6 +1092,15 @@ drm_backend_output_configure(struct wl_listener 
*listener, void *data)
api->set_seat(output, seat);
free(seat);
 
+   char *lease;
+   weston_config_section_get_string(section, "lease", , "off");
+   if (!strncmp(lease, "on", 2)) {
+   output->lease = true;
+   weston_log("Enabling lease on output %s\n", output->name);
+   }
+   free(lease);
+
+
weston_output_enable(output);
 }
 
diff --git a/configure.ac b/configure.ac
index e607cd0..97e3661 100644
--- a/configure.ac
+++ b/configure.ac
@@ -212,6 +212,10 @@ if test x$enable_drm_compositor = xyes; then
   PKG_CHECK_MODULES(DRM_COMPOSITOR_GBM, [gbm >= 10.2],
[AC_DEFINE([HAVE_GBM_FD_IMPORT], 1, [gbm supports dmabuf 
import])],
[AC_MSG_WARN([gbm does not support dmabuf import, will omit 
that capability])])
+  PKG_CHECK_MODULES(DRM_LEASE, [libdrm >= 2.4.89],
+   [AC_DEFINE([HAVE_DRM_LEASE], 1, [libdrm support lease 
capability])],
+   [AC_MSG_WARN([libdrm doesn't have leases support, will omit 
that capability])])
+
 fi
 
 
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 321ee19..a0d195d 100644
--- a/libweston/compositor-drm.c
+++ b/libweston/compositor-drm.c
@@ -62,6 +62,7 @@
 #include "presentation-time-server-protocol.h"
 #include "linux-dmabuf.h"
 #include "linux-dmabuf-unstable-v1-server-protocol.h"
+#include "drm-lease-unstable-v1-server-protocol.h"
 
 #ifndef DRM_CAP_TIMESTAMP_MONOTONIC
 #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
@@ -270,6 +271,21 @@ struct drm_backend {
uint32_t pageflip_timeout;
 
bool shutting_down;
+   struct wl_list leases;
+};
+
+struct lease {
+   int leased_fd;
+   uint32_t lessee_id;
+
+   int nobjects;
+   int tnobjects;
+   uint32_t *objects;
+
+   struct drm_output *leased_output;
+   struct wl_resource *lease_resource;
+   struct drm_backend *drm_backend;
+   struct wl_list link;
 };
 
 struct drm_mode {
@@ -423,6 +439,7 @@ struct drm_output {
int destroy_pending;
int disable_pending;
int dpms_off_pending;
+   int lease_pending;
 
struct drm_fb *gbm_cursor_fb[2];
struct drm_plane *cursor_plane;
@@ -450,6 +467,8 @@ struct drm_output {
struct wl_listener recorder_frame_listener;
 
struct wl_event_source *pageflip_timer;
+
+   struct lease *lease;
 };
 
 static struct gl_renderer_interface *gl_renderer;
@@ -1402,6 +1421,36 @@ drm_pending_state_get_output(struct drm_pending_state 
*pending_state,
 
 static int drm_pending_state_apply_sync(struct drm_pending_state *state);
 
+#ifdef HAVE_DRM_LEASE
+static void
+drm_lease_clear_objects(struct lease *lease)
+{
+   memset(lease->objects, 0, sizeof(uint32_t) * lease->tnobjects);
+   lease->tnobjects = 0;
+}
+
+static void
+drm_output_send_lease(struct drm_output *output)
+{
+   struct lease *lease = output->lease;
+   struct wl_resource *resource = lease->lease_resource;
+   int drm_fd = lease->drm_backend->drm.fd;
+
+   lease->leased_fd = drmModeCreateLease(drm_fd, lease->objects,
+ lease->tnobjects, 0,
+ >lessee_id);
+   if (lease->leased_fd < 0) {
+   drm_lease_clear_objects(lease);
+   zwp_kms_lease_request_v1_send_failed(resource);
+   return;
+   }
+
+   wl_list_insert(>drm_backend->leases, >link);
+   zwp_kms_lease_request_v1_send_created(resou

[PATCH weston 2/2 v3] clients/simple-egl-lease: A demo client for DRM leases

[Marius Vlad]

Heavily inspired by kmscube and simple-egl. Uses legacy page-flipping and
triangle shaders from simple-egl.

Signed-off-by: Marius Vlad <marius-cristian.v...@nxp.com>
---
 Makefile.am|  11 +
 clients/simple-egl-lease.c | 887 +
 clients/simple-egl-lease.h |  99 +
 configure.ac   |  17 +
 4 files changed, 1014 insertions(+)
 create mode 100644 clients/simple-egl-lease.c
 create mode 100644 clients/simple-egl-lease.h

diff --git a/Makefile.am b/Makefile.am
index 439fa73..c2bef07 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -641,6 +641,17 @@ weston_simple_dmabuf_v4l_CFLAGS = $(AM_CFLAGS) 
$(SIMPLE_DMABUF_V4L_CLIENT_CFLAGS
 weston_simple_dmabuf_v4l_LDADD = $(SIMPLE_DMABUF_V4L_CLIENT_LIBS) libshared.la
 endif
 
+if BUILD_SIMPLE_EGL_LEASE_CLIENTS
+demo_clients += weston-simple-egl-lease
+weston_simple_egl_lease_SOURCES = clients/simple-egl-lease.c
+nodist_weston_simple_egl_lease_SOURCES = 
protocol/drm-lease-unstable-v1-protocol.c \
+   protocol/drm-lease-unstable-v1-client-protocol.h
+weston_simple_egl_lease_CFLAGS = $(AM_CFLAGS) 
$(SIMPLE_EGL_LEASE_CLIENT_CFLAGS) \
+$(LIBDRM_CFLAGS)
+weston_simple_egl_lease_LDADD = $(SIMPLE_EGL_LEASE_CLIENT_LIBS) $(LIBDRM_LIBS) 
\
+   $(GBM_LIBS) -lm
+endif
+
 noinst_LTLIBRARIES += libtoytoolkit.la
 
 libtoytoolkit_la_SOURCES = \
diff --git a/clients/simple-egl-lease.c b/clients/simple-egl-lease.c
new file mode 100644
index 000..8922e57
--- /dev/null
+++ b/clients/simple-egl-lease.c
@@ -0,0 +1,887 @@
+/*
+ * Copyright 2018 NXP
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Adapted from kmscube and simple-egl. No atomic support atm.
+ *
+ */
+
+#include "config.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include "drm-lease-unstable-v1-client-protocol.h"
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include "simple-egl-lease.h"
+
+static volatile uint8_t sig_recv = 0;
+
+static const GLfloat verts[3][2] = {
+   { -0.5, -0.5 },
+   {  0.5, -0.5 },
+   {  0,0.5 }
+};
+
+static const GLfloat colors[3][3] = {
+   { 1, 0, 0 },
+   { 0, 1, 0 },
+   { 0, 0, 1 }
+};
+
+GLfloat rotation[4][4] = {
+   { 1, 0, 0, 0 },
+   { 0, 1, 0, 0 },
+   { 0, 0, 1, 0 },
+   { 0, 0, 0, 1 }
+};
+
+static const char *vertex_shader_source =
+   "uniform mat4 rotation;\n"
+   "attribute vec4 pos;\n"
+   "attribute vec4 color;\n"
+   "varying vec4 v_color;\n"
+   "void main() {\n"
+   "  gl_Position = rotation * pos;\n"
+   "  v_color = color;\n"
+   "}\n";
+
+static const char *fragment_shader_source =
+   "precision mediump float;\n"
+   "varying vec4 v_color;\n"
+   "void main() {\n"
+   "  gl_FragColor = v_color;\n"
+   "}\n";
+
+static struct gbm *
+init_gbm(int drm_fd, int w, int h)
+{
+   struct gbm *gbm = calloc(1, sizeof(*gbm));
+
+   gbm->dev = gbm_create_device(drm_fd);
+
+   gbm->surface = gbm_surface_create(gbm->dev, w, h, GBM_FORMAT_XRGB,
+ GBM_BO_USE_SCANOUT | 
GBM_BO_USE_RENDERING);
+   if (!gbm->surface) {
+   printf("failed to create gbm surface\n");
+   return NULL;
+   }
+
+   gbm->width = w;
+   gbm->height = h;
+
+   return gbm;
+}
+
+static int
+init_egl(struct egl *egl, const struct gbm *gbm)
+{
+   EGLint major, minor, n;
+
+   static con

[PATCH weston 0/2 v3] DRM lease support

[Marius Vlad]

Patch series that adds support for DRM leases.

DRM leases is a method developed by Keith Packard to allow other application 
manage the output of a display/VR, while a DRM master is already owning
the outputs resources. A more thorough explanation and terminology can
be found at [1]. libdrm [2] and kernel [3] have already gained support.

Protocol support can be found at [4].

Initially this was a single patch but decided to split into series to
accommodate a demo client as well.

Changes since v2:
- rebased as drm_output_disable() has been changed due to atomic changes
- deferring the lease when the output can't be disabled due to a pending 
flip
- client blocks until it receives a 'created'/'failed' event when
deferring the lease.
- fix a potential NULL pointer if failing to get an encoder in the client
- provide correct link to protocol
- use lessee_id instead of lease_id as per libdrm/kernel terminology

Changes since v1:
- accommodate changes due to protocol changes
- use enable/disabled for the output instead of destroy/update_outputs (Daniel 
Stone)
- split into a series, added a client example
- forcing a repaint when giving the lease and not doing a modeset if the output
has been leased avoids blank switching between the lesor and lessee

[1] https://keithp.com/blogs/DRM-lease/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f
[3] 
https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e
[4] 
https://lists.freedesktop.org/archives/wayland-devel/2018-February/036947.html


Marius Vlad (2):
  compositor-drm: Add support for DRM lease
  clients/simple-egl-lease: A demo client for DRM leases

 Makefile.am|  13 +
 clients/simple-egl-lease.c | 887 +
 clients/simple-egl-lease.h |  99 +
 compositor/main.c  |   9 +
 configure.ac   |  21 ++
 libweston/compositor-drm.c | 272 ++
 libweston/compositor.c |   1 +
 libweston/compositor.h |   2 +
 8 files changed, 1304 insertions(+)
 create mode 100644 clients/simple-egl-lease.c
 create mode 100644 clients/simple-egl-lease.h

-- 
2.9.3

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

[PATCH weston] shared/config-parser: Allow spaces/tabs at the end for

[Marius Vlad]

Signed-off-by: Marius Vlad <marius-cristian.v...@nxp.com>
---
 shared/config-parser.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/shared/config-parser.c b/shared/config-parser.c
index 2a595b1..c4bb4c3 100644
--- a/shared/config-parser.c
+++ b/shared/config-parser.c
@@ -412,6 +412,7 @@ weston_config_parse(const char *name)
struct weston_config *config;
struct weston_config_section *section = NULL;
int i, fd;
+   char *start_line, *stop_line;
 
config = malloc(sizeof *config);
if (config == NULL)
@@ -456,6 +457,10 @@ weston_config_parse(const char *name)
section = config_add_section(config, [1]);
continue;
default:
+   start_line = stop_line = line;
+   while (stop_line && *stop_line != ' ' && *stop_line != 
'\t')
+   stop_line++;
+
p = strchr(line, '=');
if (!p || p == line || !section) {
fprintf(stderr, "malformed "
@@ -474,7 +479,9 @@ weston_config_parse(const char *name)
p[i - 1] = '\0';
i--;
}
-   section_add_entry(section, line, p);
+
+   start_line[stop_line - start_line] = '\0';
+   section_add_entry(section, start_line, p);
continue;
}
}
-- 
2.9.3

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

[PATCH weston 1/3 v2] compositor-drm: Add support for drm-lease.

[Marius Vlad]

The patch relies on previous drm-lease-unstable-v1 extension protocol
posted previously [1].

Changes since v2:
- accommodate changes due to protocol changes
- use enable/disabled for the output instead of destroy/update_outputs (Daniel 
Stone)
- split into a series, added a client example
- forcing a repaint when giving the lease and not doing a modeset if the output
has been leased avoids blank switching between the lesor and lessee

Signed-off-by: Marius Vlad <marius-cristian.v...@nxp.com>
---
 Makefile.am|   2 +
 compositor/main.c  |   9 ++
 configure.ac   |   4 +
 libweston/compositor-drm.c | 244 +
 libweston/compositor.c |   1 +
 libweston/compositor.h |   2 +
 6 files changed, 262 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index e224d60..4580d24 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -178,6 +178,8 @@ nodist_libweston_@LIBWESTON_MAJOR@_la_SOURCES = 
\
protocol/viewporter-server-protocol.h   \
protocol/linux-dmabuf-unstable-v1-protocol.c\
protocol/linux-dmabuf-unstable-v1-server-protocol.h \
+   protocol/drm-lease-unstable-v1-protocol.c   \
+   protocol/drm-lease-unstable-v1-server-protocol.h\
protocol/relative-pointer-unstable-v1-protocol.c\
protocol/relative-pointer-unstable-v1-server-protocol.h \
protocol/pointer-constraints-unstable-v1-protocol.c \
diff --git a/compositor/main.c b/compositor/main.c
index 7feb4cb..779a4dd 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -1209,6 +1209,15 @@ drm_backend_output_configure(struct wl_listener 
*listener, void *data)
api->set_seat(output, seat);
free(seat);
 
+   char *lease;
+   weston_config_section_get_string(section, "lease", , "off");
+   if (!strncmp(lease, "on", 2)) {
+   output->lease = true;
+   weston_log("Enabling lease on output %s\n", output->name);
+   }
+   free(lease);
+
+
weston_output_enable(output);
 }
 
diff --git a/configure.ac b/configure.ac
index 6f295dc..e1aa0cd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -209,6 +209,10 @@ if test x$enable_drm_compositor = xyes; then
   PKG_CHECK_MODULES(DRM_COMPOSITOR_GBM, [gbm >= 10.2],
[AC_DEFINE([HAVE_GBM_FD_IMPORT], 1, [gbm supports dmabuf 
import])],
[AC_MSG_WARN([gbm does not support dmabuf import, will omit 
that capability])])
+  PKG_CHECK_MODULES(DRM_LEASE, [libdrm >= 2.4.89],
+   [AC_DEFINE([HAVE_DRM_LEASE], 1, [libdrm support lease 
capability])],
+   [AC_MSG_WARN([libdrm doesn't have leases support, will omit 
that capability])])
+
 fi
 
 
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index fe59bf5..253d0f7 100644
--- a/libweston/compositor-drm.c
+++ b/libweston/compositor-drm.c
@@ -62,6 +62,7 @@
 #include "presentation-time-server-protocol.h"
 #include "linux-dmabuf.h"
 #include "linux-dmabuf-unstable-v1-server-protocol.h"
+#include "drm-lease-unstable-v1-server-protocol.h"
 
 #ifndef DRM_CAP_TIMESTAMP_MONOTONIC
 #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
@@ -202,6 +203,21 @@ struct drm_backend {
uint32_t pageflip_timeout;
 
bool shutting_down;
+   struct wl_list leases;
+};
+
+struct lease {
+   int leased_fd;
+   uint32_t leased_id;
+
+   int nobjects;
+   int tnobjects;
+   uint32_t *objects;
+
+   struct drm_output *leased_output;
+   struct wl_resource *lease_resource;
+   struct drm_backend *drm_backend;
+   struct wl_list link;
 };
 
 struct drm_mode {
@@ -380,6 +396,9 @@ struct drm_output {
struct wl_listener recorder_frame_listener;
 
struct wl_event_source *pageflip_timer;
+
+   /** this output has been leased */
+   int leased;
 };
 
 static struct gl_renderer_interface *gl_renderer;
@@ -4837,6 +4856,225 @@ static const struct weston_drm_output_api api = {
drm_output_set_seat,
 };
 
+#ifdef HAVE_DRM_LEASE
+static void
+destroy_lease_req(struct wl_resource *params_resource)
+{
+   struct lease *lease = wl_resource_get_user_data(params_resource);
+   free(lease->objects);
+   free(lease);
+}
+
+static void
+drm_lease_add_objects(struct lease *lease, uint32_t id)
+{
+   if (lease->tnobjects > lease->nobjects) {
+   lease->nobjects *= 2;
+   lease->objects = realloc(lease->objects,
+lease->nobjects * sizeof(uint32_t));
+   }
+
+   lease->objects[lease->tnobjects++] = id;
+}
+
+static void
+drm_lease_clear_objects(struct lease *lease)
+{
+   memset(lease->objects, 0, sizeof(uint32_t) * lease->tnobjects);
+   lease->tnobjects

[PATCH weston 2/3 v2] compositor-drm: Do not perform a modeset when the output has been leased

[Marius Vlad]

This removes the blanking period until the client takes "control" of the
output, resulting in a smoother transition between weston and lease client.

Signed-off-by: Marius Vlad <marius-cristian.v...@nxp.com>
---
 libweston/compositor-drm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index 253d0f7..98e3ba4 100644
--- a/libweston/compositor-drm.c
+++ b/libweston/compositor-drm.c
@@ -4115,8 +4115,10 @@ drm_output_disable(struct weston_output *base)
output->disable_pending = 0;
 
weston_log("Disabling output %s\n", output->base.name);
-   drmModeSetCrtc(b->drm.fd, output->crtc_id,
-  0, 0, 0, 0, 0, NULL);
+   /* do not perform a modeset with a blank fb when leasing the output */
+   if (!base->lease)
+   drmModeSetCrtc(b->drm.fd, output->crtc_id,
+  0, 0, 0, 0, 0, NULL);
 
drm_output_state_free(output->state_cur);
output->state_cur = drm_output_state_alloc(output, NULL);
-- 
2.9.3

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

[PATCH weston 3/3 v2] clients/simple-egl-lease: A demo client for DRM leases

[Marius Vlad]

Heavily inspired by kmscube and simple-egl. Uses legacy page-flipping and
triangle shaders from simple-egl.

Signed-off-by: Marius Vlad <marius-cristian.v...@nxp.com>
---
 Makefile.am|  11 +
 clients/simple-egl-lease.c | 880 +
 clients/simple-egl-lease.h |  99 +
 configure.ac   |  17 +
 4 files changed, 1007 insertions(+)
 create mode 100644 clients/simple-egl-lease.c
 create mode 100644 clients/simple-egl-lease.h

diff --git a/Makefile.am b/Makefile.am
index 4580d24..8177313 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -656,6 +656,17 @@ weston_simple_dmabuf_v4l_CFLAGS = $(AM_CFLAGS) 
$(SIMPLE_DMABUF_V4L_CLIENT_CFLAGS
 weston_simple_dmabuf_v4l_LDADD = $(SIMPLE_DMABUF_V4L_CLIENT_LIBS) libshared.la
 endif
 
+if BUILD_SIMPLE_EGL_LEASE_CLIENTS
+demo_clients += weston-simple-egl-lease
+weston_simple_egl_lease_SOURCES = clients/simple-egl-lease.c
+nodist_weston_simple_egl_lease_SOURCES = 
protocol/drm-lease-unstable-v1-protocol.c \
+   protocol/drm-lease-unstable-v1-client-protocol.h
+weston_simple_egl_lease_CFLAGS = $(AM_CFLAGS) 
$(SIMPLE_EGL_LEASE_CLIENT_CFLAGS) \
+$(LIBDRM_CFLAGS)
+weston_simple_egl_lease_LDADD = $(SIMPLE_EGL_LEASE_CLIENT_LIBS) $(LIBDRM_LIBS) 
\
+   $(GBM_LIBS) -lm
+endif
+
 noinst_LTLIBRARIES += libtoytoolkit.la
 
 libtoytoolkit_la_SOURCES = \
diff --git a/clients/simple-egl-lease.c b/clients/simple-egl-lease.c
new file mode 100644
index 000..7425120
--- /dev/null
+++ b/clients/simple-egl-lease.c
@@ -0,0 +1,880 @@
+/*
+ * Copyright 2018 NXP
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Adapted from kmscube and simple-egl. No atomic support atm.
+ *
+ */
+
+#include "config.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include "drm-lease-unstable-v1-client-protocol.h"
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include "simple-egl-lease.h"
+
+static volatile uint8_t sig_recv = 0;
+
+static const GLfloat verts[3][2] = {
+   { -0.5, -0.5 },
+   {  0.5, -0.5 },
+   {  0,0.5 }
+};
+
+static const GLfloat colors[3][3] = {
+   { 1, 0, 0 },
+   { 0, 1, 0 },
+   { 0, 0, 1 }
+};
+
+GLfloat rotation[4][4] = {
+   { 1, 0, 0, 0 },
+   { 0, 1, 0, 0 },
+   { 0, 0, 1, 0 },
+   { 0, 0, 0, 1 }
+};
+
+static const char *vertex_shader_source =
+   "uniform mat4 rotation;\n"
+   "attribute vec4 pos;\n"
+   "attribute vec4 color;\n"
+   "varying vec4 v_color;\n"
+   "void main() {\n"
+   "  gl_Position = rotation * pos;\n"
+   "  v_color = color;\n"
+   "}\n";
+
+static const char *fragment_shader_source =
+   "precision mediump float;\n"
+   "varying vec4 v_color;\n"
+   "void main() {\n"
+   "  gl_FragColor = v_color;\n"
+   "}\n";
+
+static struct gbm *
+init_gbm(int drm_fd, int w, int h)
+{
+   struct gbm *gbm = calloc(1, sizeof(*gbm));
+
+   gbm->dev = gbm_create_device(drm_fd);
+
+   gbm->surface = gbm_surface_create(gbm->dev, w, h, GBM_FORMAT_XRGB,
+ GBM_BO_USE_SCANOUT | 
GBM_BO_USE_RENDERING);
+   if (!gbm->surface) {
+   printf("failed to create gbm surface\n");
+   return NULL;
+   }
+
+   gbm->width = w;
+   gbm->height = h;
+
+   return gbm;
+}
+
+static int
+init_egl(struct egl *egl, const struct gbm *gbm)
+{
+   EGLint major, minor, n;
+
+   static con

[PATCH weston 0/3 v2] DRM lease support

[Marius Vlad]

Patch series that adds support for DRM leases. 

DRM leases is a method developed by Keith Packard to allow other application 
manage the output of a display/VR, while a DRM master is already owning
the outputs resources. A more thorough explanation and terminology can
be found at [1]. libdrm [2] and kernel [3] have already gained support.

Initially this was a single patch but decided to split into series to
accommodate a demo client and another change as to allow a smoother transition
of the output from weston to a DRM leased client.

Marius Vlad (3):
  compositor-drm: Add support for drm-lease.
  compositor-drm: Do not perform a modeset when the output has been
leased
  clients/simple-egl-lease: A demo client for DRM leases

[1] https://keithp.com/blogs/DRM-lease/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f
[3] 
https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e


 Makefile.am|  13 +
 clients/simple-egl-lease.c | 880 +
 clients/simple-egl-lease.h |  99 +
 compositor/main.c  |   9 +
 configure.ac   |  21 ++
 libweston/compositor-drm.c | 250 -
 libweston/compositor.c |   1 +
 libweston/compositor.h |   2 +
 8 files changed, 1273 insertions(+), 2 deletions(-)
 create mode 100644 clients/simple-egl-lease.c
 create mode 100644 clients/simple-egl-lease.h

-- 
2.9.3

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

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

[Marius Vlad]

Simple protocol extension to manage DRM lease. Based on the work by Keith
Packard in [1], respectively [2].

[1] 
https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f

Signed-off-by: Marius Vlad <marius-cristian.v...@nxp.com>

Changes since v1:
- added manager: advertise lease capability and manage the lease (Daniel Stone)
- add request(s) for adding connector/crtc/plane to behave more like dmabuf 
(Daniel Stone)
---
 Makefile.am  |   1 +
 unstable/drm-lease/README|   4 +
 unstable/drm-lease/drm-lease-unstable-v1.xml | 150 +++
 3 files changed, 155 insertions(+)
 create mode 100644 unstable/drm-lease/README
 create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..4f6a874 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,6 +2,7 @@ unstable_protocols =
\
unstable/pointer-gestures/pointer-gestures-unstable-v1.xml  
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
+   unstable/drm-lease/drm-lease-unstable-v1.xml
\
unstable/text-input/text-input-unstable-v1.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
diff --git a/unstable/drm-lease/README b/unstable/drm-lease/README
new file mode 100644
index 000..a25600c
--- /dev/null
+++ b/unstable/drm-lease/README
@@ -0,0 +1,4 @@
+Linux DRM lease
+
+Maintainers:
+Marius Vlad <marius-cristian.v...@nxp.com>
diff --git a/unstable/drm-lease/drm-lease-unstable-v1.xml 
b/unstable/drm-lease/drm-lease-unstable-v1.xml
new file mode 100644
index 000..907efb0
--- /dev/null
+++ b/unstable/drm-lease/drm-lease-unstable-v1.xml
@@ -0,0 +1,150 @@
+
+
+
+  
+Copyright 2018 NXP
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+
+  This interface makes use of DRM lease written by Keith Packard.
+
+  A DRM master can create another DRM master and ``lease'' resources it has
+  control over to the new DRM master. Once leased, resources can not be
+  controlled by the owner unless the owner cancels the lease, or the new
+  DRM master is closed.
+
+  A lease is a contract between the Lessor (DRM master which has leased out
+  resources to one or more other DRM masters) and a Lessee
+  (DRM master which controls resources leased from another DRM master). 
This
+  contract specifies which resources may be controlled by the Lessee.
+
+  The Lessee can issue modesetting/page-flipping atomic operations etc.,
+  just like a Lesor using the leased file-descriptor passed by the Lesor.
+
+  Besides the leased file-description, an integer is used to uniquely
+  identify a Lessee within the tree of DRM masters descending from a single
+  Owner. Once the Lessee has finished with the resources it had used, the
+  Lessee ID can be used to revoke that lease.
+
+  Warning! The protocol described in this file is experimental and
+  backward incompatible changes may be made. Backward compatible changes
+  may be added together with the corresponding interface version bump.
+  Backward incompatible changes are done by bumping the version number in
+  the protocol and interface names and resetting the interface version.
+  Once the protocol is to be declared stable, the 'z' prefix and the
+  version number in 

[PATCH weston] desktop-shell: Correctly migrate views to other outputs when output is disabled/disconnected

[Marius Vlad]

Our case is when the view is the same as output being disabled/disconnected.
There's not need to check the views' output with the output being disabled
because weston_view_assign_output() already changes the output of the view when
the output has been disabled/disconnected hence the check is not needed at all.

The views' output will always be different than the output being disabled.

By the time shell_output_destroy_move_layer() gets called the views' output has
already changed to a "free" output. Tested this by unplugging/disabling the
output on purpose.

Signed-off-by: Marius Vlad <marius-cristian.v...@nxp.com>
---
 desktop-shell/shell.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index de76ebe..d9dffd2 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -4698,12 +4698,8 @@ shell_output_destroy_move_layer(struct desktop_shell 
*shell,
struct weston_output *output = data;
struct weston_view *view;
 
-   wl_list_for_each(view, >view_list.link, layer_link.link) {
-   if (view->output != output)
-   continue;
-
+   wl_list_for_each(view, >view_list.link, layer_link.link)
shell_reposition_view_on_output_destroy(view);
-   }
 }
 
 static void
-- 
2.9.3

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

[PATCH weston] RFC: libweston/compositor-drm: Add support for drm-lease.

[Marius Vlad]

DRM leases is a method developed by Keith Packard to allow other application
manage the output of a display/VR, while a DRM master is already owning the
outputs resources. A more thorough explanation and terminology can be found at
[1].

This patch adds support for DRM lease. libdrm is lease-aware in 2.4.89,
while the kernel support has landed in Linus's master tree (4.15).

The easiest way to choose which output to lease is to have a 'lease' entry for
the output in the config file. My assumption is based on the fact that one would
not want to destroy/close the application running on a particular output. Upon
leasing an output to a client that output will no longer be managed by weston.
When the application is done with the lease it will send a revoke request,
moment in which weston will reclaim the output.

For instance the following configuration file can lease HDMI-A-1 output to other
application.

[output]
name=HDMI-A-1
lease=on

The patch relies on previous drm-lease-unstable-v1 extension protocol
posted previously [4].

[1] https://keithp.com/blogs/DRM-lease/
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f
[3] 
https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e
[4] 
https://lists.freedesktop.org/archives/wayland-devel/2018-January/036652.html

Signed-off-by: Marius Vlad <marius-cristian.v...@nxp.com>
---
 Makefile.am|   2 +
 compositor/main.c  |  10 +++
 configure.ac   |   4 +-
 libweston/compositor-drm.c | 204 -
 libweston/compositor.c |   1 +
 libweston/compositor.h |   3 +
 man/weston.ini.man |   8 ++
 7 files changed, 230 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e224d60..9a5fcb9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -178,6 +178,8 @@ nodist_libweston_@LIBWESTON_MAJOR@_la_SOURCES = 
\
protocol/viewporter-server-protocol.h   \
protocol/linux-dmabuf-unstable-v1-protocol.c\
protocol/linux-dmabuf-unstable-v1-server-protocol.h \
+   protocol/drm-lease-unstable-v1-protocol.c   \
+   protocol/drm-lease-unstable-v1-server-protocol.h\
protocol/relative-pointer-unstable-v1-protocol.c\
protocol/relative-pointer-unstable-v1-server-protocol.h \
protocol/pointer-constraints-unstable-v1-protocol.c \
diff --git a/compositor/main.c b/compositor/main.c
index 7feb4cb..bf1712c 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -1186,6 +1186,7 @@ drm_backend_output_configure(struct wl_listener 
*listener, void *data)
modeline = s;
s = NULL;
}
+
free(s);
 
if (api->set_mode(output, mode, modeline) < 0) {
@@ -1208,6 +1209,15 @@ drm_backend_output_configure(struct wl_listener 
*listener, void *data)
 
api->set_seat(output, seat);
free(seat);
+#ifdef HAVE_DRM_LEASE
+   char *lease;
+   weston_config_section_get_string(section, "lease", , "off");
+   if (!strncmp(lease, "on", 2)) {
+   output->lease = true;
+   weston_log("Enabling lease on output %s\n", output->name);
+   }
+   free(lease);
+#endif
 
weston_output_enable(output);
 }
diff --git a/configure.ac b/configure.ac
index 6f295dc..444666b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -209,9 +209,11 @@ if test x$enable_drm_compositor = xyes; then
   PKG_CHECK_MODULES(DRM_COMPOSITOR_GBM, [gbm >= 10.2],
[AC_DEFINE([HAVE_GBM_FD_IMPORT], 1, [gbm supports dmabuf 
import])],
[AC_MSG_WARN([gbm does not support dmabuf import, will omit 
that capability])])
+  PKG_CHECK_MODULES(DRM_LEASE, [libdrm >= 2.4.89],
+   [AC_DEFINE([HAVE_DRM_LEASE], 1, [libdrm support lease 
capability])],
+   [AC_MSG_WARN([libdrm doesn't have leases support, will omit 
that capability])])
 fi
 
-
 PKG_CHECK_MODULES(LIBINPUT_BACKEND, [libinput >= 0.8.0])
 PKG_CHECK_MODULES(COMPOSITOR, [$COMPOSITOR_MODULES])
 
diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
index fe59bf5..98c2e6b 100644
--- a/libweston/compositor-drm.c
+++ b/libweston/compositor-drm.c
@@ -62,6 +62,7 @@
 #include "presentation-time-server-protocol.h"
 #include "linux-dmabuf.h"
 #include "linux-dmabuf-unstable-v1-server-protocol.h"
+#include "drm-lease-unstable-v1-server-protocol.h"
 
 #ifndef DRM_CAP_TIMESTAMP_MONOTONIC
 #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
@@ -386,6 +387,30 @@ static struct gl_renderer_interface *gl_renderer;
 
 static const char default_seat[] = "seat0";
 
+#ifdef HAVE_DRM_LEASE
+/* hold current leases given */
+static struct wl_list leases;
+
+struct d

[PATCH wayland-protocols] RFC: unstable: DRM lease support

[Marius Vlad]

Simple protocol extension for DRM leases, based on the work done 
by Keith Packard in libdrm [1] and in the Linux kernel [2].

There are two requests (create/revoke) and three events
(created/revoked/failed). The server is responsible for choosing which output to
lease. Another patch will follow that makes use of this procotol extension.

[1] 
https://cgit.freedesktop.org/mesa/drm/commit/?id=c4171535389d72e9135c9615cecd07b346fd6d7e
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.15-rc9=62884cd386b876638720ef88374b31a84ca7ee5f

Signed-off-by: Marius Vlad <marius-cristian.v...@nxp.com>
---
 Makefile.am  |  1 +
 unstable/drm-lease/README|  4 ++
 unstable/drm-lease/drm-lease-unstable-v1.xml | 98 
 3 files changed, 103 insertions(+)
 create mode 100644 unstable/drm-lease/README
 create mode 100644 unstable/drm-lease/drm-lease-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..4f6a874 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,6 +2,7 @@ unstable_protocols =
\
unstable/pointer-gestures/pointer-gestures-unstable-v1.xml  
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
+   unstable/drm-lease/drm-lease-unstable-v1.xml
\
unstable/text-input/text-input-unstable-v1.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
diff --git a/unstable/drm-lease/README b/unstable/drm-lease/README
new file mode 100644
index 000..a25600c
--- /dev/null
+++ b/unstable/drm-lease/README
@@ -0,0 +1,4 @@
+Linux DRM lease
+
+Maintainers:
+Marius Vlad <marius-cristian.v...@nxp.com>
diff --git a/unstable/drm-lease/drm-lease-unstable-v1.xml 
b/unstable/drm-lease/drm-lease-unstable-v1.xml
new file mode 100644
index 000..ec67456
--- /dev/null
+++ b/unstable/drm-lease/drm-lease-unstable-v1.xml
@@ -0,0 +1,98 @@
+
+
+
+  
+Copyright 2018 NXP
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+
+  This interface makes use of DRM lease written by Keith Packard.
+  It requires libdrm at least 2.4.89 and a recent (4.15) kernel.
+
+  Events:
+
+  - created -- event sent when the lease has been created succesfully
+  - revoked -- event sent when the lease has been revoked succesfully
+  - failed -- event sent when create/revoke requests failed.
+
+  Requests:
+
+  - create -- asks the server to create a lease. The server decides which
+  ouput to lease to the client. In case of success, the client receives
+  an event with a DRM capable-fd. The client can then issue libdrm
+  ioctls (i.e., modesetting).  The client also receives a lessee_id which
+  has be used in revoke request. In case of failure, a failed event will
+  be sent.
+  - revoke -- asks the server to revoke a previously leased fd, using the
+  lessee_id.
+  A revoke event will be sent in case of success or failed event otherwise.
+
+  Warning! The protocol described in this file is experimental and
+  backward incompatible changes may be made. Backward compatible changes
+  may be added together with the corresponding interface version bump.
+  Backward incompatible changes are done by bumping the version number in
+  the protocol and interface names and resetting the interface version.
+  Once the protocol is to be declared stable, the 'z' prefix and the
+  version number in the protocol and interface names are removed and the
+  i

[PATCH] Allow to specify wayland-protocols datadir

[Marius Vlad]

This is particularly useful when cross-compiling and we need to specify a custom
datadir path for wayland-protocols. Cross-compilation toolchain is usually
immutable, and in this way we can modify wayland-protocols independently from
what the toolchain provides.

Signed-off-by: Marius Vlad <marius-cristian.v...@nxp.com>
---
 configure.ac | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index d1b5f47..11ebc21 100644
--- a/configure.ac
+++ b/configure.ac
@@ -213,7 +213,13 @@ PKG_CHECK_MODULES(COMPOSITOR, [$COMPOSITOR_MODULES])
 
 PKG_CHECK_MODULES(WAYLAND_PROTOCOLS, [wayland-protocols >= 1.8],
  [ac_wayland_protocols_pkgdatadir=`$PKG_CONFIG 
--variable=pkgdatadir wayland-protocols`])
-AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, $ac_wayland_protocols_pkgdatadir)
+AC_ARG_WITH(wayland-protocols-datadir-path,
+   AS_HELP_STRING([--with-wayland-protocols-datadir-path=PATH],
+   [Path to wayland-protocols]),
+   [WAYLAND_PROTOCOLS_DATADIR="$withval"],
+   [WAYLAND_PROTOCOLS_DATADIR="$ac_wayland_protocols_pkgdatadir"])
+
+AC_SUBST([WAYLAND_PROTOCOLS_DATADIR])
 
 AC_ARG_ENABLE(wayland-compositor, [  --enable-wayland-compositor],,
  enable_wayland_compositor=yes)
-- 
2.9.3

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