05 t440 kernel: [ 6.366655] input: SynPS/2 Synaptics
> TouchPad as /devices/platform/i8042/serio1/input/input2
>
> This without even rebooting or suspending the laptop.
>
> I have some scripts that disable or enable the touchpad (especially
> when
> I use the mouse) and I
ed and structured, but please keep in mind the
> coding standards (which happen to overlap greatly with the GNU ones):
> https://www.gnu.org/prep/standards.
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
there generally will be a
bit of Q 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,
Lyude Paul (she/her)
Software
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,
Lyude
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,
Lyude
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
there generally will be a
bit of Q 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
begins.
Lyude Paul, on behalf of the X.Org elections committee
in the
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
in the
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
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
of 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
/Elections/2022/
Lyude Paul,
On behalf of the X.Org elections committee
/Elections/2022/
Lyude Paul,
On behalf of the X.Org elections committee
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, 2021-07-14 at 16:32 -0400, Lyude Paul wrote:
> H
:).
--
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
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 waiting for a review/merge on a patch, etc. and I
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/xorg-devel
Info: https://lists.x.org/mailman
t; 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
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!
--
Cheers,
Lyude Paul
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
Archives: http
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_display.c |
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
ot specify -masterfd when server is
> setuid/setgid\n");
> +if (sscanf(argv[++i], "%d", ) != 1) {
> +UseMsg();
> +xf86DRMMasterFd = -1;
> +return 0;
> +}
> +return 2;
> +}
> +
> return 0;
>
gt; *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 this, but I ca
#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 insertions(+), 1
e_crtc->reset_fb_id = FALSE;
> drmmode_crtc->rotate_fb_id = 0;
>
> drmmode_bo_destroy(drmmode, _crtc->rotate_bo);
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h
> b/hw/xfree86/drivers/modesetting/drmmode_display.
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) {
>
(errno == ENODEV) {
> > > + *name = handle;
> > > + return TRUE;
> > > + } else {
> > > + return FALSE;
> > > + }
> > > +}
> > > *name = flink.name;
> > > return TRUE;
> > > }
> > > --
> > > 2.14.3
> >
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
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 v1:
-
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")
---
glamo
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
> >
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
(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@lists.x.org: X.Org
lly 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@lists.x.org: X.Org development
A
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
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_display.c
b/hw/xfree86/drivers/m
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,
>
}
> @@ -201,7 +234,7 @@ xwl_glamor_init(struct xwl_screen *xwl_screen)
> return FALSE;
> }
>
> -if (!xwl_screen->egl_backend.init_screen(xwl_screen)) {
> + if (!xwl_screen->egl_backend->init_screen(xwl_screen)) {
> ErrorF("E
xwl_screen,
> struct wl_registry *registry,
> uint32_t id, const char *interface,
> uint32_t version);
> +Bool xwl_glamor_has_wl_interface(struct xwl_screen *xwl_screen);
> void xwl
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 compatibil
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 Lyude: yo
Reviewed-by: Lyude Paul <ly...@redhat.com>
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 <ofour...@redhat.com>
> ---
> hw/
Reviewed-by: Lyude Paul <ly...@redhat.com>
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 s
Reviewed-by: Lyude Paul <ly...@redhat.com>
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 d
Reviewed-by: Lyude Paul <ly...@redhat.com>
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 abor
Reviewed-by: Lyude Paul <ly...@redhat.com>
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 supp
xwl_glamor_should_use_gbm(void);
> void **xwl_glamor_egl_get_devices(int *num_devices);
> Bool xwl_glamor_egl_device_has_egl_extensions(void *device,
>const char **ext_list,
--
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
t; > + } else {
> > + drmGetMagic(xwl_gbm->drm_fd, );
> > + wl_drm_authenticate(xwl_gbm->drm, magic);
> > + }
> > +}
>
> e.g. here, the change to expecting_event is unnecessary; the previous
> code explicitly decremented and re-incr
lgtm! for the whole series:
Reviewed-by: Lyude Paul <ly...@redhat.com>
On Fri, 2018-04-20 at 14:38 -0400, Adam Jackson wrote:
> From: Lyude Paul <ly...@redhat.com>
>
> This takes all of the gbm related code in wayland-glamor.c and moves it
> into it's own EGL backen
/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 <ly...@redhat.com>
---
Xext/meson.build | 6 +-
meson
No functional changes, just fixing a tabs vs. space error I noticed
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
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
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 | 26
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 backend.
Signed-off-by: Lyude Paul <ly...@redhat.
-by: Lyude Paul <ly...@redhat.com>
---
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/xway
Just a small autogenerated header that will soon contain more then just
one macro.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
configure.ac | 7 +++
hw/xwayland/xwayland.c | 10 ++
hw/xwayland/xwayland.h | 2 +-
include/meson
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 glamor
xwayland:
Just a small autogenerated header that will soon contain more then just
one macro.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
configure.ac | 7 +++
hw/xwayland/xwayland.c | 10 ++
hw/xwayland/xwayland.h | 2 +-
include/meson
-by: Lyude Paul <ly...@redhat.com>
---
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/xway
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 backend.
Signed-off-by: Lyude Paul <ly...@redhat.
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 backend.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
configure.ac| 24
Just a small autogenerated header that will soon contain more then just
one macro.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
configure.ac | 7 +++
hw/xwayland/xwayland.c | 10 ++
hw/xwayland/xwayland.h | 2 +-
include/meson
-by: Lyude Paul <ly...@redhat.com>
---
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/xway
or 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.am |
.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
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
n 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 <ly...@redhat.com>
---
Just a quick note!!! I haven't actually tested at all whether or not
this breaks cursor
Changes since v2:
- Don't enable by default for debugoptimized builds
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
include/meson.build | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/meson.build b/include/meson.build
index 5d746eb70..ce933ca43
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 <ly...@redhat.com&
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
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
to that.
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
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-by: Lyude
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
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
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
Ben Skeggs (1):
fix null pointer deref when building against >=libdrm 2.4.78
Ilia Mirkin (1):
Add Pascal family support, identical to Maxwell
Lyude (1):
Bump version to 1.0.15
Mariusz Bialonczyk (1):
Do not register hotplug without RandR
git tag:
Ilia Mirkin (7):
exa: add GM10x acceleration support
hwdefs: update nvc0_3d, add gm107_texture for new TIC format
nvc0: make use of the new hwdefs for TEX_CB_INDEX
nvc0: rename BEGIN_IMC0 to IMMED_NVC0
nvc0: refactor TIC uploads to allow different specifics per
I'm up for this. Better then having to send the same patches for both radeon and
amdgpu to seperate mailing lists :)
Cheers,
Lyude
On Wed, 2016-06-22 at 17:57 +0900, Michel Dänzer wrote:
> This is a heads up that we'll be using the amd-...@lists.freedesktop.org
> mailing list for
90 matches
Mail list logo
