Hi Connor,
Since the development of r128 DDX has stalled for about two years, I was
looking to obtain xf86-video-* DDX commit privilege so that I can add KMS
support to r128 DDX.
Although some additional work remain (function renaming and removal of unused
code), I have gotten to the point
Sweet! Everything looks good to me
For the whole series:
Reviewed-by: Lyude Paul
On Tue, 2018-06-05 at 19:38 +0200, Olivier Fourdan wrote:
> Hi,
>
> This is a follow-up on https://patchwork.freedesktop.org/series/44095/
> after Lyude and Emil reviews.
>
> Cheers,
> Olivier
>
> Olivier
On 5 June 2018 at 18:38, Olivier Fourdan wrote:
> xwl_glamor_eglstream_init_egl() uses "EGL_IMG_context_priority"
> extension, make sure it's actually available before using it.
>
> Suggested-by: Emil Velikov
> Signed-off-by: Olivier Fourdan
> ---
> hw/xwayland/xwayland-glamor-eglstream.c | 6
On 5 June 2018 at 18:28, Olivier Fourdan wrote:
> Hi Emil,
>
> Many thanks for your detailed review!
>
> On Tue, Jun 5, 2018 at 12:37 PM, Emil Velikov
> wrote:
>> Hi Olivier,
>>
>> There's a handful of mostly trivial suggestions below. The idea itself seems
>> reasonable IMHO. One gripe is that
On 2018-06-05 05:33 AM, Michel Dänzer wrote:
> On 2018-06-05 05:00 AM, Kevin Brace wrote:
>> I do have OpenChrome related commit privilege and I wanted to extend it to
>> other xf86-video-* DDXs.
>> I did post several patches over at xorg-driver-ati mailing list if that is
>> what is needed to
Now that we have separate backends for EGLStream and GBM, we can
explicitly check for the EGLStream backend to disable present support
in that case.
Signed-off-by: Olivier Fourdan
---
hw/xwayland/xwayland-present.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
xwl_glamor_eglstream_init_egl() uses "EGL_IMG_context_priority"
extension, make sure it's actually available before using it.
Suggested-by: Emil Velikov
Signed-off-by: Olivier Fourdan
---
hw/xwayland/xwayland-glamor-eglstream.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
Introduces a new egl_backend function to let the EGL backend check for
the presence of the required Wayland interfaces.
Signed-off-by: Olivier Fourdan
---
hw/xwayland/xwayland-glamor-eglstream.c | 28 ++---
hw/xwayland/xwayland-glamor-gbm.c | 14 +
To be able to check for availability of the Wayland interfaces required
to run a given EGL backend (either GBM or EGLStream for now), we need
to have each backend structures and vfuncs in place before we enter the
Wayland registry dance.
That basically means that we should init all backends at
Surely, we should fail to init GBM backend if "GL_OES_EGL_image" is
missing.
This seems to have been lost with commit 1545e2dba ("xwayland: Decouple
GBM from glamor").
Suggested-by: Emil Velikov
Signed-off-by: Olivier Fourdan
---
hw/xwayland/xwayland-glamor-gbm.c | 4 +++-
1 file changed, 3
Move EGL backends initialization to its own function in
xwayland-glamor.c
Signed-off-by: Olivier Fourdan
---
hw/xwayland/xwayland-glamor.c | 17 +
hw/xwayland/xwayland.c| 16 ++--
hw/xwayland/xwayland.h| 2 ++
3 files changed, 21 insertions(+), 14
Both xwl_glamor_init_wl_registry() and the Wayland global registry
handler use the interface id/name in that order, using name/id in the
egl_backend vfunc makes things confusing and error prone.
Signed-off-by: Olivier Fourdan
---
hw/xwayland/xwayland-glamor-eglstream.c | 4 ++--
EGL backend availability requires both EGL extensions and Wayland
interfaces to be present, so we will need to consider multiple backends
during initialization.
As a preliminary work, move the egl_backend to its own struct so that we
can have more than one backend at any given time.
Functions such as:
xwl_glamor_egl_supports_device_probing()
xwl_glamor_egl_get_devices()
xwl_glamor_egl_device_has_egl_extensions()
Are of no use outside of EGLStream support, move them to the relevant
source file.
Similarly, the other glamor functions such as:
xwl_glamor_init()
If using a render node, we can skip DRM authentication.
Suggested-by: Emil Velikov
Signed-off-by: Olivier Fourdan
---
hw/xwayland/xwayland-glamor-gbm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/xwayland/xwayland-glamor-gbm.c
b/hw/xwayland/xwayland-glamor-gbm.c
index
Make xwl_output_get_xdg_output() private, it doesn't need to be
available elsewhere.
Signed-off-by: Olivier Fourdan
Reviewed-by: Lyude Paul
Reviewed-by: Emil Velikov
---
hw/xwayland/xwayland-output.c | 4 +++-
hw/xwayland/xwayland.h| 1 -
2 files changed, 3 insertions(+), 2
EGLStream requires glamor, but the opposite is not true. So if someone
passes "-eglstream" with a GPU which does not support EGLStream, we
could maybe still try GBM and be lucky.
That allows Wayland compositors to pass "-eglstream" regardless of the
actual hardware, if they want to enable
Hi,
This is a follow-up on https://patchwork.freedesktop.org/series/44095/
after Lyude and Emil reviews.
Cheers,
Olivier
Olivier Fourdan (10):
xwayland: move glamor specific routines
xwayland: swap "name" and "id" in init_wl_registry()
xwayland: GBM should fail w/out "GL_OES_EGL_image"
When we're done adding a new screen, we need to process any pending
Wayland events again.
Hence we don't end up processing xdg_output events unexpectedly when
glamor is disabled. Be that because "-shm" was passed or "-eglstream"
has failed.
Failing to do that could lead to a crash at startup:
eglQueryDevicesEXT() would abort if the required extensions are not
available, meaning that enabling “-eglstream” on a non-EGLStream
capable hardware would lead to an abort().
Check that "EGL_EXT_device_base" extension is available and bail out
early if not, so we don't abort() later in
The command line option "-eglstream" used to enable EGLStream support
for NVidia GPU was made available only when Xwayland was built with
EGLStream support enabled.
Wayland compositors who spawn Xwayland have no easy way to tell whether
or not Xwayland was built with EGLStream support enabled,
Hi,
This is a follow-up on https://patchwork.freedesktop.org/series/43704/
after Lyude and Emil reviews.
Emil, for 1/5, I changed the error message if eglstream wasn't enabled at
build time to:
"xwayland glamor: this build does not have eglstream support"
which sounds to me like the most
Hi Emil,
Many thanks for your detailed review!
On Tue, Jun 5, 2018 at 12:37 PM, Emil Velikov wrote:
> Hi Olivier,
>
> There's a handful of mostly trivial suggestions below. The idea itself seems
> reasonable IMHO. One gripe is that we're 'leaking' twice as much as before.
>
> Namely: even if
> Michal Srb hat am 31. Mai 2018 um 15:12 geschrieben:
>
>
> There is no point in adding entry or merging lists if a FamilyWild entry would
> end in front of any entry, or entry without display number would end in front
> of entry with number.
>
> This sorts all entries in order:
> *
Hi Emil,
On 5 June 2018 at 12:41, Emil Velikov wrote:
> [...]
>
>> > +#else
> >> > +ErrorF("xwayland glamor: eglstream backend support not
> >> > enabled\n");
> >> Something is really weird here:
> >>
> >> On one hand '-eglstream' is recognised and used (by potential user) on
> >>
On 4 June 2018 at 15:37, Olivier Fourdan wrote:
> Hi
>
> On 4 June 2018 at 16:24, Emil Velikov wrote:
>>
>> On 24 May 2018 at 15:10, Olivier Fourdan wrote:
>> > The command line option "-eglstream" used to enable EGLi stream support
>> > for NVidia GPU was made available only when Xwayland was
Hi Olivier,
There's a handful of mostly trivial suggestions below. The idea itself seems
reasonable IMHO. One gripe is that we're 'leaking' twice as much as before.
Namely: even if the current backend cleans-up after itself (it some cases it
does not), the other backend 'leaks'. Not sure if/how
On 1 June 2018 at 15:31, Olivier Fourdan wrote:
> +static Bool
> +xwl_glamor_gbm_has_wl_interfaces(struct xwl_screen *xwl_screen)
> +{
> +struct xwl_gbm_private *xwl_gbm = xwl_gbm_get(xwl_screen);
> +
> +if (xwl_gbm->drm == NULL) {
> +ErrorF("glamor: 'wl_drm' not supported\n");
>
On 1 June 2018 at 15:31, Olivier Fourdan wrote:
> EGL backend availability requires both EGL extensions and Wayland
> interfaces to be present, so we will need to consider multiple backends
> during initialization.
>
> As a preliminary work, move the egl_backend to its own struct so that we
> can
Avoid access to System V shared memory segment on the X server side
for clients forwarded via SSH. Also prevent them from hanging while
waiting for the reply from the ShmCreateSegment request.
v2: Allow ShmQueryVersion request even for remote clients
Bugzilla:
On 2018-06-05 05:00 AM, Kevin Brace wrote:
>
> I do have OpenChrome related commit privilege and I wanted to extend it to
> other xf86-video-* DDXs.
> I did post several patches over at xorg-driver-ati mailing list if that is
> what is needed to earn this privilege.
Connor Behan has been
31 matches
Mail list logo
