ier is better since there generally will be a
bit of Q&A with organizers.
And if you just have some questions about what organizing XDC entails,
please feel free to chat with previous organizers, or someone from the
board.
Best regards,
Lyude Paul
On behalf of X.org
--
Cheers,
L
d me an email to
x...@codeweavers.com, adding on CC the X.org board (board
at foundation.x.org).
And don't forget, you can follow us on Twitter for all the latest
updates and to stay connected:
https://twitter.com/XOrgDevConf
Best regards,
Lyude Paul, on behalf of X.org
--
Cheers,
L
d me an email to
x...@codeweavers.com, adding on CC the X.org board (board
at foundation.x.org).
And don't forget, you can follow us on Twitter for all the latest
updates and to stay connected:
https://twitter.com/XOrgDevConf
Best regards,
Lyude Paul, on behalf of X.org
--
Cheers,
L
d me an email to
x...@codeweavers.com, adding on CC the X.org board (board
at foundation.x.org).
And don't forget, you can follow us on Twitter for all the latest
updates and to stay connected:
https://twitter.com/XOrgDevConf
Best regards,
Lyude Paul, on behalf of X.org
oard (board
at foundation.x.org).
And don't forget, you can follow us on Twitter for all the latest
updates and to stay connected:
https://twitter.com/XOrgDevConf
Best regards,
Lyude Paul, on behalf of X.org
ier is better since there generally will be a
bit of Q&A with organizers.
And if you just have some questions about what organizing XDC entails,
please feel free to chat with previous organizers, or someone from the
board.
Best regards,
Lyude Paul
On behalf of X.org
that Emma Anholt, Alyssa Rosenzweig, Mark Filion and
Ricardo Garcia were elected for two year terms.
The old full board is: Emma Anholt, Samuel Iglesias Gonsálvez, Mark
Filion, Manasi D Navare, Keith Packard, Lyude Paul, Daniel Vetter, Harry
Wentland
The new full board is: Emma Anholt, Samuel
eriod begins.
Lyude Paul, on behalf of the X.Org elections committee
upcoming election is 31 March 2022 at 23:59 UTC.
If you are interested in joining the X.Org Foundation or in renewing
your membership, please visit the membership system site at:
https://members.x.org/
Lyude Paul, on behalf of the X.Org elections committee
were Lyude Paul,
Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will
continue to serve until their term ends in 2023. Current directors whose term
expires in 2022 are Emma Anholt, Keith Packard, Harry Wentland and Mark
Filion.
A director is expected to participate in the
will serve as directors for two year
terms.
The directors who received two year terms starting in 2021 were Lyude Paul,
Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will
continue to serve until their term ends in 2023. Current directors whose term
expires in 2022 are Emma Anholt
directors elected from the membership. Each year, an
election is held to bring the total number of directors to eight. The four
members receiving the highest vote totals will serve as directors for two year
terms.
The directors who received two year terms starting in 2021 were Lyude Paul,
Samuel
/Elections/2022/
Lyude Paul,
On behalf of the X.Org elections committee
/Elections/2022/
Lyude Paul,
On behalf of the X.Org elections committee
ts
in areas that wouldn't be eligible for GSoC would still have a chance at
participating in a project. Outreachy also helps fill this gap, as I don't
believe they have the same kind of international restrictions that GSoC does.
* What is the expected result, a grading?
Yes.
On Wed, 2
e myself wouldn't be in
this community without projects like GSoC :).
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
munity. As well, the
board believes OFTC's current Governance model is a lot more clear then
Libera's.
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are
nizing XDC entails,
please feel free to chat with previous organizers, or someone from the
board.
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/
hat would be helpful to me
> in properly interpreting data from monitors that are (ostensibly) built
> to that spec.
>
> Regards,
> Sanford Rockowitz
>
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
.
The current plan is to extend VESA membership to X.Org members who
specifically request it. If you think you'd be at all interested in this, or
know any projects or contributors who would be, please feel free to respond to
this message and let me know!
a few
different projects to figure out who all would be interested in such training.
If there's any takers, or anyone has any questions, feel free to respond and
let us know!
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Arch
o an empty dependency to fix that.
Signed-off-by: Lyude Paul
---
meson.build | 1 +
1 file changed, 1 insertion(+)
diff --git a/meson.build b/meson.build
index 53cdbe2be..29794f083 100644
--- a/meson.build
+++ b/meson.build
@@ -407,6 +407,7 @@ if not build_xv
endif
build_dga = false
+xf86dg
Reviewed-by: Lyude Paul
On Thu, 2018-07-05 at 02:27 -0700, Tony Lindgren wrote:
> Looks like drmModeDirtyFB() stopped working at some point and we now
> call it with fb_id of zero for rotated displays. This will stop displays
> relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display
On Thu, 2018-06-28 at 12:39 -0700, Keith Packard wrote:
> Lyude Paul writes:
>
> > Looks good! One nitpick I'm not 100% sure about:
> > > +#define CHECK_FOR_REQUIRED_ARGUMENT() \
> > > +if (((i + 1) >= argc) || (!argv[i + 1])) {
This got reviewed off-list by Karol Herbst . It's a no-
brainer, so I'll push it in just a moment
On Wed, 2018-06-27 at 20:30 -0400, Lyude Paul wrote:
> This really sucked to find out :(
>
> Signed-off-by: Lyude Paul
> ---
> hw/xfree86/drivers/modesetting/drmmode_d
This really sucked to find out :(
Signed-off-by: Lyude Paul
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 375be4234..e27139d0e
ror("\nCannot specify -masterfd when server is
> setuid/setgid\n");
> +if (sscanf(argv[++i], "%d", &xf86DRMMasterFd) != 1) {
> +UseMsg();
> +xf86DRMMasterFd = -1;
> +return 0;
> +}
> +return 2;
&g
> > > +}
> > > *name = flink.name;
> > > return TRUE;
> > > }
> > > --
> > > 2.14.3
> > >
> > > ___
> > > Sent to linux-graphics-maintai...@vmware.com
>
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
yes if you wouldn't mind, after that I'll add it to the modesetting pull
On Fri, 2018-06-22 at 00:28 -0700, Tony Lindgren wrote:
> * Lyude Paul [180621 22:55]:
> > Hey, was a patch updated re: Keith's comments ever posted for this? Was
> > going
> > to review
ctory
#include
^~~
compilation terminated.
So, in the event that we can't use libtirpc ensure that we actually
check whether or not the libc provides rpc/rpc.h. If it doesn't, raise
an error.
Signed-off-by: Lyude Paul
---
os/meson.build | 6 +-
1 file changed, 5 i
0;
> +drmmode_crtc->reset_fb_id = FALSE;
> drmmode_crtc->rotate_fb_id = 0;
>
> drmmode_bo_destroy(drmmode, &drmmode_crtc->rotate_bo);
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h
> b/hw/xfree86/drivers/mode
On Thu, 2018-06-21 at 08:38 +0100, Daniel Stone wrote:
> Hey Lyude,
> On Thu, 21 Jun 2018 at 00:13, Lyude Paul wrote:
> > -/* Pixmaps with multi-planes/modifier are not supported in this
> > interface */
> > -if (ret != 1 || offsets[0] != 0) {
>
*/
> > > + if (errno == ENODEV) {
> > > + *name = handle;
> > > + return TRUE;
> > > + } else {
> > > + return FALSE;
> > > + }
> > > +}
> > > *name = flink.name;
> > > return TRUE;
> > > }
> &
On Mon, 2018-06-18 at 14:50 -0400, Lyude Paul wrote:
> Hey guys! So, talking to Ajax he said that something which would probably
> help
> out with getting a bugfix release out there for X is if people started
> getting
> their changes together into pull requests so that he doe
This seems like a problem worth screaming about.
Signed-off-by: Lyude Paul
---
randr/rrcrtc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index d7d937e80..74dc5a265 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -534,6 +534,7 @@ rrSetupPixmapSharing
both glamor_fds_from_pixmap() and
glamor_fd_from_pixmap() that calls down to the appropriate
glamor_egl_fd*_from_pixmap() function.
Signed-off-by: Lyude Paul
Cc: Louis-Francis Ratté-Boulianne
Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
---
Changes since
both glamor_fds_from_pixmap() and
glamor_fd_from_pixmap() that calls down to the appropriate
glamor_egl_fd*_from_pixmap() function.
Signed-off-by: Lyude Paul
Cc: Louis-Francis Ratté-Boulianne
Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
---
This seems like a problem worth screaming about.
Signed-off-by: Lyude Paul
---
randr/rrcrtc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index d7d937e80..74dc5a265 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -534,6 +534,7 @@ rrSetupPixmapSharing
On Wed, 2018-06-20 at 16:46 +0200, Thomas Hellstrom wrote:
> On 06/18/2018 10:48 PM, Lyude Paul wrote:
> > To help ajax out with getting a bug release out for Xorg, we figured it
> > would
> > be a good idea for me to go through the stuff I needed to get upstream and
> >
On Wed, 2018-06-20 at 16:46 +0200, Thomas Hellstrom wrote:
> On 06/18/2018 10:48 PM, Lyude Paul wrote:
> > To help ajax out with getting a bug release out for Xorg, we figured it
> > would
> > be a good idea for me to go through the stuff I needed to get upstream and
> >
ulling time (which should
hopefully not be too long from now).
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Reviewed-by: Lyude Paul
On Fri, 2018-06-15 at 08:57 +0200, Olivier Fourdan wrote:
> drmmode_shadow_allocate() still uses drmModeAddFB() which may fail if
> the format is not as expected, preventing from using a rotated output.
>
> Change it to use the new function drmmode_bo_im
h=xwayland
(thanks Olivier for putting everything in one place!)
If anyone else has EGLStream related stuff they would like to get in that I
missed, it's probably a good idea to respond to this!
--
Cheers,
Lyude Paul
___
xorg-devel@lis
ot;
you're not actually contributing anything useful to the discussion, especially
if you don't actually provide any points as to "gitlab is bad because of X or
Y reason".
>
> -JimC
--
Cheers,
Lyude Paul
___
xorg-devel@li
Reviewed-by: Lyude Paul
On Mon, 2018-06-11 at 10:22 +0200, Olivier Fourdan wrote:
> The API init_wl_registry() and has_wl_interfaces() are marked as being
> optional, but both GBM And EGLStream backends implement them so there is
> point in keeping those optional.
>
> Suggested-b
s, and X
won't be able to reclaim them.
Signed-off-by: Lyude Paul
Cc: Louis-Francis Ratté-Boulianne
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/hw/xfree86/drivers/modesetting/drmmode_dis
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,
>
ErrorF("EGL setup failed, disabling glamor\n");
> return FALSE;
> }
> @@ -201,7 +234,7 @@ xwl_glamor_init(struct xwl_screen *xwl_screen)
> return FALSE;
> }
>
> -if (!xwl_screen->egl_backend.init_screen(xwl_screen)) {
> +i
l_glamor_init_wl_registry(struct xwl_screen
> *xwl_screen,
> struct wl_registry *registry,
> uint32_t id, const char *interface,
> uint32_t version);
> +Bool xwl_glamor_has_wl_interf
Reviewed-by: Lyude Paul
On Wed, 2018-05-30 at 11:19 +0200, Olivier Fourdan wrote:
> Check for "EGL_MESA_platform_gbm" in the avaiable EGL extensions, and
> try automatically EGL stream if not present.
>
> The command line options “-eglstream” is kept for compatibility to
On Mon, 2018-05-28 at 09:11 +0200, Olivier Fourdan wrote:
> Hey Luyde,
>
> On Fri, May 25, 2018 at 7:54 PM, Lyude Paul wrote:
> > NAK, unfortunately this check isn't going to be enough, see:
> >
> >
> >
> > 2018-05-24 15:44:34 jadahl Lyud
Reviewed-by: Lyude Paul
On Thu, 2018-05-24 at 16:11 +0200, Olivier Fourdan wrote:
> Make xwl_output_get_xdg_output() private, it doesn't need to be
> available elsewhere.
>
> Signed-off-by: Olivier Fourdan
> ---
> hw/xwayland/xwayland-output.c | 4 +++-
> hw/xway
Reviewed-by: Lyude Paul
On Thu, 2018-05-24 at 16:33 +0200, Olivier Fourdan wrote:
> EGL stream requires glamor, but the opposite is not true. So if someone
> passes "-eglstream" with a GPU which does not support EGL stream, we
> could maybe still try GBM and be lucky.
>
Reviewed-by: Lyude Paul
On Thu, 2018-05-24 at 16:11 +0200, Olivier Fourdan wrote:
> When we're done adding a new screen, we need to process pending Wayland
> events again so that we don't end up processing xdg_output events when
> unexpected if glamor is disabled (either
Reviewed-by: Lyude Paul
On Thu, 2018-05-24 at 16:11 +0200, Olivier Fourdan wrote:
> eglQueryDevicesEXT() would abort if the required extenon are not
> available, meaning that enabling “-eglstream”on a non-EGL stream capable
> hardware would lead to an abort().
>
Reviewed-by: Lyude Paul
On Thu, 2018-05-24 at 16:10 +0200, Olivier Fourdan wrote:
> The command line option "-eglstream" used to enable EGLi stream support
> for NVidia GPU was made available only when Xwayland was built with EGL
> stream support enabled.
>
> Wayl
-- a/hw/xwayland/xwayland.h
> +++ b/hw/xwayland/xwayland.h
> @@ -444,6 +444,7 @@ void xwl_screen_init_xdg_output(struct xwl_screen
> *xwl_screen);
>
> void xwl_glamor_egl_make_current(struct xwl_screen *xwl_screen);
> Bool xwl_glamor_egl_supports_device_probing(void);
> +Bool xwl_gla
; > + } else {
> > + drmGetMagic(xwl_gbm->drm_fd, &magic);
> > + wl_drm_authenticate(xwl_gbm->drm, magic);
> > + }
> > +}
>
> e.g. here, the change to expecting_event is unnecessary; the previous
>
lgtm! for the whole series:
Reviewed-by: Lyude Paul
On Fri, 2018-04-20 at 14:38 -0400, Adam Jackson wrote:
> From: Lyude Paul
>
> This takes all of the gbm related code in wayland-glamor.c and moves it
> into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
> Addi
lxDispatchReset':
/home/lyudess/Projects/xserver/glx/vndcmds.c:468: undefined reference to
`ht_destroy'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
So, make sure that hashtable.c gets both for both glx and res
Signed-off-by: Lyude Paul
---
Xext/meson.b
No functional changes, just fixing a tabs vs. space error I noticed
Signed-off-by: Lyude Paul
---
glx/meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/glx/meson.build b/glx/meson.build
index dc7aab962..69d558e78 100644
--- a/glx/meson.build
+++ b/glx
t our rendering priority to
high, speeds things up a tiny bit more.
Lyude Paul (3):
xwayland: Decouple GBM from glamor
xwayland: Add xwayland-config.h
xwayland: Add glamor egl_backend for EGLStreams
configure.ac| 31 ++
hw/xwayland/Makefile.am
on to the GBM debate, but merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when
ned-off-by: Lyude Paul
---
hw/xwayland/Makefile.am | 3 +-
hw/xwayland/meson.build | 1 +
hw/xwayland/xwayland-glamor-gbm.c | 632 ++
hw/xwayland/xwayland-glamor.c | 500 +-
hw/xwayland/xwayland.c|
Just a small autogenerated header that will soon contain more then just
one macro.
Signed-off-by: Lyude Paul
---
configure.ac | 7 +++
hw/xwayland/xwayland.c | 10 ++
hw/xwayland/xwayland.h | 2 +-
include/meson.build
veau-shm.log
3: nv-eglstream.log
4: nv-shm.log
1 2 3 4Operation
-
63800.0 23500.0 27600.0 27100.0 Copy 500x500 from pixmap to window
Unfortunately, not that great :(
Lyude Paul (3):
xwayland: Decouple GBM from glam
Just a small autogenerated header that will soon contain more then just
one macro.
Signed-off-by: Lyude Paul
---
configure.ac | 7 +++
hw/xwayland/xwayland.c | 10 ++
hw/xwayland/xwayland.h | 2 +-
include/meson.build
ned-off-by: Lyude Paul
---
hw/xwayland/Makefile.am | 3 +-
hw/xwayland/meson.build | 1 +
hw/xwayland/xwayland-glamor-gbm.c | 632 ++
hw/xwayland/xwayland-glamor.c | 500 +-
hw/xwayland/xwayland.c|
on to the GBM debate, but merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when
merely a baindaid so our users
don't have to suffer from the consequences of companies avoiding working
upstream. New drivers are strongly encouraged not to use this as a
backend, and use GBM like everyone else. We even spit this out as an
error from Xwayland when using the eglstream ba
Just a small autogenerated header that will soon contain more then just
one macro.
Signed-off-by: Lyude Paul
---
configure.ac | 7 +++
hw/xwayland/xwayland.c | 10 ++
hw/xwayland/xwayland.h | 2 +-
include/meson.build
ned-off-by: Lyude Paul
---
hw/xwayland/Makefile.am | 3 +-
hw/xwayland/meson.build | 1 +
hw/xwayland/xwayland-glamor-gbm.c | 628 ++
hw/xwayland/xwayland-glamor.c | 500 +-
hw/xwayland/xwayland.c|
helpers with this, for the day when mesa
grows the ability to support extensions.
Lyude Paul (3):
xwayland: Decouple GBM from glamor
xwayland: Add xwayland-config.h
xwayland: Add glamor egl_backend for EGLStreams
configure.ac| 31 ++
hw/xwayland/Makefile.a
p yet.
Signed-off-by: Lyude Paul
---
hw/xwayland/xwayland.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 19aa14a47..9b1d85674 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -265,6 +265,9 @@ xwl_close_screen(Scre
So, actually return NULL in xwl_screen_get_default_seat() if the seat
list is empty, and skip any pointer confinement processing in
xwl_cursor_confined_to() when we don't have a seat setup yet.
Signed-off-by: Lyude Paul
---
Just a quick note!!! I haven't actually tested at all whether or not
et to [], gets passed
to executable() in the link_with array, and then gets removed by array
flattening.
This also unbreaks Xwayland builds with -Dglx=false, the thing that
originally made me notice this.
Signed-off-by: Lyude Paul
---
glx/meson.build| 2 +-
hw/dmx/meson.build | 2 +-
meson.
Changes since v2:
- Don't enable by default for debugoptimized builds
Signed-off-by: Lyude Paul
---
include/meson.build | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/meson.build b/include/meson.build
index 5d746eb70..ce933ca43 100644
--- a/include/meson.
Warnings come from the fact that PRIx32 is not used for printing 32 bit
values instead of "%lx", and "%lx" evaluates to a 64 bit long on 64 bit
systems while PRIx32 always evaluates to the right type for the
respective arch.
Signed-off-by: Lyude Paul
---
hw/xfree86/x86emu
Signed-off-by: Lyude Paul
---
hw/xfree86/int10/meson.build | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/xfree86/int10/meson.build b/hw/xfree86/int10/meson.build
index 3bcf99ab4..b1ead9c4c 100644
--- a/hw/xfree86/int10/meson.build
+++ b/hw/xfree86/int10/meson.build
@@ -25,6 +25,12
.
This series makes it so meson defines DEBUG when the buildtype is debug,
while additionally also fixing all of the compiler warnings/errors this
causes in the default configuration.
Lyude Paul (4):
fbdevhw: Fix inconsistent #if DEBUG usage
x86emu: Fix type conversion warnings on x86_64 with
fbdevhw is the only file in X's source that actually uses #if DEBUG to
check for debugging instead of #ifdef DEBUG. This is contrary to
everything else that checks the DEBUG macro in the source, so let's make
it consistent and in turn, make our meson files a little simpler.
Signed-off
Signed-off-by: Lyude Paul
---
include/meson.build | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/meson.build b/include/meson.build
index 90f8de3cb..8894885c6 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -196,6 +196,9 @@ conf_data.set
this post-install junk is making
sure that we can control the directory that X uses for finding the
xkbcomp binary from meson so we can point it at the system provided
xkbcomp (/usr/bin/xkbcomp or similar). So, this patch adds a
configuration option for controlling this called xkb_bin_dir.
Signed-off
83 matches
Mail list logo
