I would start by figuring out exactly why accept() is failing. You could
use strace for this, or a patch like:
https://gitlab.freedesktop.org/ajax/libxtrans/-/commit/0cf78fc5b4156f0053a6a332f97b4652ed54cb6a
Note that to make that patch work you need to patch libxtrans and then
rebuild xserver
No, just MAXCLIENTS. Probably vkcube (or the driver it's using) should fail
more robustly when it can't connect to the display, instead of letting you
render without presenting though.
On Fri, May 5, 2023 at 5:28 PM Anuj Phogat wrote:
> Hi All,
>
> I've been trying to run the maximum number of
I missed that! My apologies. I've merged the reentrancy patch, we should
probably push out another release shortly.
- ajax
On Tue, Nov 1, 2022 at 8:16 PM Po Lu wrote:
>
>
> On November 2, 2022 1:25:06 AM GMT+08:00, Adam Jackson
> wrote:
> >On Mon, Oct 31, 2022 at 8:
On Mon, Oct 31, 2022 at 8:46 PM Po Lu wrote:
> Adam Jackson writes:
>
> > Because XInitThreads only works if it is called before XOpenDisplay.
>
> So why not fix that?
>
> I think the simple fix would be to call _XInitDisplayLock in
> XGetXCBConnection.
>
Th
Bah, meant to reply all here.
- ajax
-- Forwarded message -
From: Adam Jackson
Date: Mon, Oct 31, 2022 at 12:29 PM
Subject: Re: XInitThreads in library constructor breaks Motif!
To: Po Lu
On Sun, Oct 30, 2022 at 8:10 PM Po Lu wrote:
>
> Or most people are on Xlib
On Mon, Oct 31, 2022 at 8:18 AM Po Lu wrote:
If there is really a big problem with clients using XCB, then why not
> call XInitThreads in XGetXCBConnection instead?
>
Because XInitThreads only works if it is called before XOpenDisplay.
- ajax
On Tue, 2020-07-07 at 13:13 -0700, x...@pengaru.com wrote:
> Hello list,
>
> I'm trying to use XShmCreatePixmap() in combination with XCopyArea()
> to achieve something resembling an XShmGetSubImage() for copying
> damaged areas piecemeal out of the root window into a shmseg for a
> screencap
On Tue, 2020-04-14 at 17:28 +0800, Aaron Ma wrote:
> EDID1.4 replaced GTF Bit with Continuous or Non-Continuous Frequency Display.
There's a lot that's weird about this patch but:
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
>
On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote:
> On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > > pre-merge CI.
> >
> > Thanks for the suggestion! I
Does anyone have strong opinions on this? I would really like to bump
to at least 0.49 for the position-independent executable support. If
not that, 0.47 gives us 'feature' support for build options, which
addresses the "should we enable this by default or not" question in a
consistent way.
-
On Tue, 2020-03-17 at 10:12 -0700, Jacob Lifshay wrote:
> One related issue with explicit sync using sync_file is that combined
> CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> rendering in userspace (like llvmpipe but for Vulkan and with extra
> instructions for GPU tasks) but
On Wed, 2020-03-11 at 12:31 -0500, Jason Ekstrand wrote:
> - X11: With present, it has these "explicit" fence objects but
> they're always a shmfence which lets the X server and client do a
> userspace CPU-side hand-off without going over the socket (and
> round-tripping through the kernel).
On Sat, 2020-02-08 at 15:46 +0100, Egil Möller wrote:
> Hi!
>
> I have for a time now been working on a new composing window manager
> to try
> out a few UX ideas (https://redhog.github.io/InfiniteGlass videos:
> https://www.youtube.com/watch?v=vbt7qtwiLiM
>
On Wed, 2019-12-25 at 12:52 -0600, Kevin Brace wrote:
> From: Kevin Brace
>
> Signed-off-by: Kevin Brace
What's the provenance of these changes? I've seen some hacked packages
for additional SiS device support but never got around to merging them
all up, would be good to know where this came
On Wed, 2019-12-04 at 18:24 +0800, cheng...@emindsoft.com.cn wrote:
> From: Chen Gang
>
> The global (un)lock xserver operations will have effect to the whole
> system, and all the other gui apps have to be blocked, so the operations
> should not be buffered, or may cause sync issue, e.g. reboot
On Sun, 2019-11-24 at 23:04 +0100, Thomas Klausner wrote:
> Thanks for the hint!
>
> Is anything else from this list effectively dead?
Yes:
> libXevie
Not implemented in xserver since 1.6 (late 2008), rarely used by any
clients.
> libXxf86misc
Likewise. This is the client-side part of
On Fri, 2019-11-15 at 11:08 +0100, Thomas Klausner wrote:
> Hi!
>
> I've updated pkgsrc to use xorgproto 2019.2, still installing the
> legacy headers with --enable-legacy, and we had to fix a couple
> conflicts:
>
> * XKBgeom.h is provided by libX11 1.6.9
> * vlcXvMC.h is provided by libXvMC
On Tue, 2019-10-08 at 22:19 +0200, Hans de Goede wrote:
> Hi,
>
> On 08-10-2019 18:28, Adam Jackson wrote:
>
> > In short, releases need to happen, and we have CI, so let's just pop a
> > release out on scheduled dates assuming CI passes.
>
> Given that th
I gave a brief lightning talk about this at XDC Montreal [1], and
nobody seemed to object, but here's a recap for those who weren't
present or have other ideas or preferences.
In short, releases need to happen, and we have CI, so let's just pop a
release out on scheduled dates assuming CI passes.
On Mon, 2019-07-29 at 14:36 +0100, Ralph Corderoy wrote:
> Is there any chance X.org can ship their super collection of fonts as
> OpenType bitmaps as well? I understand it's a mechanical conversion.
> That would allow distro packagers to make them readily available to
> users alongside the
On Mon, 2019-07-22 at 12:53 -0400, Felix Miata wrote:
> No joy:
> (EE) TSENG(0): No valid Framebuffer address in PCI config space;
>
> Does this mean the ET6100 needs manual configuration of PCI Bus ID? Other?
I think it means the driver is broken, now. Repairable, but.
Specifically:
> [
On Sun, 2019-07-21 at 10:08 +0100, Jon Turney wrote:
> On 16/07/2019 20:07, Adam Jackson wrote:
> > On Mon, 2019-07-15 at 14:31 -0700, Alan Coopersmith wrote:
> > > On 7/15/19 4:02 AM, Thomas Klausner wrote:
> > >
> > > > libWindowsWM
> > >
&g
On Sun, 2019-07-21 at 09:29 -0400, Felix Miata wrote:
> Adam Jackson composed on 2019-07-16 15:33 (UTC-0400):
>
> > On Sun, 2019-07-14 at 18:34 -0700, Alan Coopersmith wrote:
>
> > > - driver/xf86-video-tseng
>
> > These are drivers for some fairly anc
On Sun, 2019-07-14 at 18:34 -0700, Alan Coopersmith wrote:
> - driver/xf86-video-ark
> - driver/xf86-video-tseng
These are drivers for some fairly ancient PCI devices, both Tseng Labs
and Ark Logic were out of the graphics chip business by 1999. If
someone wants to verify that they work with
On Mon, 2019-07-15 at 14:31 -0700, Alan Coopersmith wrote:
> On 7/15/19 4:02 AM, Thomas Klausner wrote:
>
> > libWindowsWM
>
> This is supposed to only be useful on Cygwin, but a Cygwin package search
> says they don't ship it, and it hasn't had a release since 2009, so I
> wonder if anyone
On Mon, 2019-06-17 at 10:08 -0400, Matt Turner wrote:
> Thanks. Are you familiar with the Xorg release scripts [0]? There's a
> wiki page at [1] that has instructions.
>
> If for any reason you have trouble making the release or uploading the
> tarball, let me know and I'll be happy to handle
ade the most recent changes:
>
> Ville Syrjälä: ville.syrj...@linux.intel.com (found via a commit
> message with sign-off tag)
> Eric Anholt: e...@anholt.net
> Adam Jackson: a...@nwnk.net
I don't have an active development interest in the intel driver, I just
ship it. My most rece
On Mon, 2019-05-06 at 23:40 +0200, Ulrich Sibiller wrote:
> On Mon, May 6, 2019 at 6:28 PM Alan Coopersmith
> wrote:
> > On 5/6/19 9:20 AM, Ulrich Sibiller wrote:
> > > Since that code is really old (the PANORAMIX stuff came in with
> > > XFree86 4.3.0.1 in November 2003) I am wondering if this
I was asked off-list what tasks are involved in releasing a new X
server, since eventually people are probably going to want one.
And that's a good question! The unfortunate answer is that the process
has been informal and has varied over time. We have often used tracking
bugs in bugzilla to
On Wed, 2019-03-06 at 17:04 +0100, Luc Verhaegen wrote:
> Is there a reason why, of _all_ drivers listed in
>
> https://cgit.freedesktop.org/xorg/driver
>
> the Radeonhd repository at
>
> https://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/
>
> has not been mirrored?
Pretty sure I
On Tue, 2019-02-26 at 08:20 -0500, James Larrowe wrote:
> I'm working on nonintrusively patching Xlib and the X server to work
> natively on Windows 32-bit, and I'm interested in upstreaming the
> patches. I have two questions:
> 1. Would they be welcome?
Almost certainly, although I'm not sure
On Sun, 2019-02-24 at 12:58 -0800, Alan Coopersmith wrote:
> I come not to praise the Katamari, but to bury it...
>
> Signed-off-by: Alan Coopersmith
Reviewed-by: Adam Jackson
- ajax
___
xorg-devel@lists.x.org: X.Org development
Archi
Hey, I need one of these, so I've got a merge request posted with some
bugfixes from master backported:
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/125
If there's anything in there you hate, or anything not in there that
should be, give a shout. I'd like to push this out sometime
On Fri, 2019-02-15 at 17:00 -0800, Alan Coopersmith wrote:
> but I'm guessing instead we should have some sort of callback or ddx-specific
> initialization called from inputthread, that happens to be an empty stub
> everywhere but the xf86 ddx for Solaris.
Yeah, that sounds better. Bool
On Tue, 2019-02-12 at 17:22 +0100, Kevin Brace wrote:
> I am able to compile X Server, although I do not know at this point
> how to install it to my preferred location (I will like to install it
> to /opt for testing purposes).
On Fri, 2019-02-08 at 10:19 -0800, Andy Ritger wrote:
> (1) If configured for PRIME GPU offloading (environment variable or
> application profile), client-side libglvnd could load the possible
> libGLX_${vendor}.so libraries it finds, and call into each to
> find which vendor (and
On Tue, 2019-02-05 at 02:58 +0100, Kevin Brace wrote:
> Hi,
>
> I know the devices in question were abandoned in late 1990s, but can
> someone take those two DDXs out of archived status over at GitLab?
> I do have 4 patches I will like to commit into xf86-video-apm [1].
De gustibus non est
On Wed, 2019-01-23 at 14:22 -0800, Alan Coopersmith wrote:
> I've confirmed with our kernel folks that the syscall we call from
> xf86EnableIO() on Solaris has always only set the IOPL for the calling
> thread and not other threads. They believe the primary difference between
> Linux & Solaris
On Tue, 2019-01-15 at 23:21 +0100, Carlos Garnacho wrote:
> This will be dissociated in future commits to handle the cases
> where windows are being realized before there is a compositor
> handling redirection.
>
> In that case, we still want the DamagePtr to be registered upfront
> on
On Wed, 2019-01-16 at 11:52 +0200, Pekka Paalanen wrote:
> What I think we would need is a way to launch Xwayland, but ensure it
> does not process the real X11 apps until all the preparations (xrdb,
> XWM init, etc.) have finished. What the preparations are exactly, only
> the Wayland compositor
On Sat, 2019-01-12 at 12:18 +, Tuomo Rinne wrote:
> The correct fix would be to use #ifdef statements in the xf86-video-vmware
> driver correct? I'm happy to send a patch if this is the case.
I think that's the best fix. xserver's never going to do
#define XSERVER_LIBPCIACCESS 0
so using
On Mon, 2018-12-17 at 23:54 +0100, Kevin Brace wrote:
> The rendering is fine for the login screen as far as I am concerned,
> so I would imagine that EXA can theoretically support 24 bpp, but no
> one really tried since by the time EXA was developed, every new
> graphics had 32 bpp support, and
On Thu, 2018-12-13 at 22:32 -0600, Kevin Brace wrote:
> It appears that people who developed EXA forgot that there used to be
> graphics devices that used 24-bits (3 bytes) instead of 32-bits (4 bytes)
> in order to display one pixel. The lack of 24-bit color support inside
>
I've turned off new bug entry in bugzilla for the X server and the
modesetting driver. Please use gitlab issues for all new reports:
https://gitlab.freedesktop.org/xorg/xserver/issues
Existing bugs can still be modified, but will eventually be migrated
into gitlab as well. They've not been
On Tue, 2018-11-20 at 09:34 -0800, Eric Anholt wrote:
> Alan Coopersmith writes:
>
> > While iterating over all the /xorg/ repos to update their READMEs
> > (which I think I've now finished - let me know if you spot one I missed),
> > I noticed a few more to consider archiving:
>
> I agree with
I've been looking at cleaning up pixmap format and visual
initialization. I'm having some difficulty understanding why the code
is currently doing what it's doing. Perhaps someone has an idea.
In the initial connection block, a DEPTH is a tuple of a depth and a
list of visuals. A VISUALTYPE is a
On Mon, 2018-11-19 at 18:06 +0100, Samuel Thibault wrote:
> Hello,
>
> Ping?
Tsk, thought I'd pushed this already. Merged, thanks:
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/77
- ajax
___
xorg-devel@lists.x.org: X.Org development
rg/wiki/Development/Documentation/SubmittingPatches;>
> + url="https://www.x.org/wiki/Development/Documentation/SubmittingPatches;>
I've updated this wiki page to talk about gitlab first, and moved the
email-based workflow to the end.
Series is:
Reviewed-by: Adam Jackson
- ajax
___
On Mon, 2018-11-12 at 13:48 -0800, Manoj Gupta wrote:
> Is this the right mailing list for this patch? If not, please advise.
This is the right list, although we're generally moving to gitlab for
patch submission:
https://gitlab.freedesktop.org/xorg/xserver/
> diff --git a/config/udev.c
On Mon, 2018-11-12 at 13:51 +0100, Michal Srb wrote:
> The screensaver can regularly move its window to random offsets. It should
> use the ConfigureWindow function instead of calling the Screen's MoveWindow
> directly. Some MoveWindow implementations, such as compMoveWindow, rely on
> Screen's
On Wed, 2018-11-07 at 22:56 +0100, Samuel Thibault wrote:
> Adam Jackson, le mer. 07 nov. 2018 15:09:58 -0500, a ecrit:
> > Because the kernel is the one thing in a position to enforce access
> > exclusion.
>
> root-owned processes can still use ioperm to get access to
On Wed, 2018-11-07 at 18:27 +0100, Samuel Thibault wrote:
> Adam Jackson, le mer. 07 nov. 2018 12:04:52 -0500, a ecrit:
> > On Mon, 2018-11-05 at 22:56 +1100, Damien Zammit wrote:
> >
> > > I wish to propose an additional api call to libpciaccess.
> > > Before I s
On Mon, 2018-11-05 at 18:25 +, Simon Ser wrote:
> On Monday, November 5, 2018 3:24 PM, Pekka Paalanen
> wrote:
> > I don't think it's a good idea to break Xwayland completely on
> > compositors that don't implement wl_surface version 4 or greater.
> >
> > It would make sense to bind
On Mon, 2018-11-05 at 22:56 +1100, Damien Zammit wrote:
> I wish to propose an additional api call to libpciaccess.
> Before I submit a patch, I wish to get some feedback from the devs.
>
> In GNU/Hurd currently, applications use the x86 backend from
> libpciaccess. This poses concurrency issues
On Mon, 2018-11-05 at 13:41 +0200, hoshi wrote:
> Hi, I have tested on some user applications (Emacs, gedit,...) and
> found that Mod4+O, Mod4+P is not sent to the applications. Instead,
> they show the cursor (if it's hidden). I am not sure if this is due
> to Xorg or other programs.
I don't
On Tue, 2018-10-16 at 17:02 +0200, René Rebe wrote:
> I now requested access (rener) on the new gitlab site.
The top-level 'xorg' group implies access to all subprojects, which
we'd like to keep to a minimum. I've added you as a Maintainer to
xorg/drivers/xf86-video-impact, if you need
I've enabled filing gitlab issues for xserver, as people were trying to
file bugs against xorg/meta (which is not the right place). Expect
bugzilla migration to start happening later this week and take... well,
I don't know how long, I'll be attempting to triage/close old issues as
I go and I
On Thu, 2018-10-11 at 16:45 +0200, Michal Srb wrote:
> If the X server is terminated while its VT is not active, it should
> not change the current VT.
> ---
> Changing the VT in that situation serves no purpose and can be confusing.
> For example when a user's graphical session is terminated
On Mon, 2018-10-01 at 11:31 -0400, Adam Jackson wrote:
> AFAICT the free(dst) is always wrong. The other places we use
> drmmode_prop_info_copy, we're initializing an array in the middle of a
> drmmode_{crtc,output}_private_rec.
https://gitlab.freedesktop.org/xorg/xserver/merge_re
On Wed, 2018-09-12 at 11:01 +1000, Dave Airlie wrote:
> On Wed, 28 Feb 2018 at 11:21, Daniel Stone wrote:
> >
> > +static Bool
> > +drmmode_prop_info_copy(drmmode_prop_info_ptr dst,
> > + const drmmode_prop_info_rec *src,
> > + unsigned int num_props,
>
On Tue, 2018-09-11 at 15:41 -0400, Alex Deucher wrote:
> On Tue, Sep 11, 2018 at 1:30 PM Julien Isorce wrote:
> >
> > Useful when video decoders only output NV12. Currently
> > glamor Xv only supports I420 and YV12.
> >
> > Note that Intel's sna supports I420, YV12, YUY2, UYVY, NV12.
> >
> >
On Mon, 2018-09-10 at 10:28 -0400, Adam Jackson wrote:
> If you haven't logged into patchwork yet and turned on notifications
^
Erk, that should say gitlab not patchwork.
- ajax
___
xorg-devel@lists.x.org: X.
I've turned merge requests on for most modules. I haven't done the
drivers yet (hopefully by the end of the day), and will continue to
leave them disabled for the drivers whose maintainers have asked they
be left disabled.
In particular, merge requests are enabled for xserver now, and that's
how
continued from pixman@, original thread here:
https://lists.freedesktop.org/archives/pixman/2018-August/004759.html
On Wed, 2018-08-29 at 18:14 +0200, Frédéric Fauberteau wrote:
> Le 2018-08-29 16:33, Adam Jackson a écrit :
> > This is a curious backtrace though. You're crashing whi
:
xfree86: Remove the rest of ->SetOverscan (2018-08-20 14:55:35 -0400)
----
Adam Jackson (8):
xf86cmap: Factor out private lookup
xf86cmap: Remove numColors from the colormap private
xf86cmap: Remove overscan machin
gitlab groups are recursive, which means if you are a member of the
'xorg' group, your permission level for every project in that group is
at least as high as your permission at the top level. Most of the
existing accounts were set as Maintainer, at which level you can do
things like read and set
On Mon, 2018-02-05 at 17:00 -0500, Adam Jackson wrote:
> Well that was fast! Got a copy of the cvsroot for 3.x/4.x, hooray. I'll
> take a crack at importing that to git once xserver 1.20 is out.
https://gitlab.freedesktop.org/ajax/xfree86
On Mon, 2018-06-11 at 12:33 +0200, Michel Dänzer wrote:
> As the maintainer of xf86-video-amdgpu and -ati, I'm fine with migrating
> these to GitLab for Git and patch review.
>
> However, I'm not sure what to do about bugs/issues. My first thought was
> to allow creating new issues in GitLab and
On Wed, 2018-08-08 at 10:37 +1000, Peter Hutterer wrote:
> but either way, series is
> Reviewed-by: Peter Hutterer
Merged (except 6/10), thanks:
remote: remote: I: patch #243247 updated using rev
513d52d58915f291c0f706b67b8dc73f45de109f.
remote: remote: I: patch #243245 updated using
On Tue, 2018-08-07 at 16:23 -0700, Eric Anholt wrote:
> Dependencies are ported from the automake build. The only part I
> skipped was making sure we can find libaudit.h.
Fair enough, but then:
> +build_xselinux = get_option('xselinux')
> +if build_xselinux
> +if not build_xace
> +
On Thu, 2018-08-09 at 12:25 -0400, Adam Jackson wrote:
> From: "vadym.shovkoplias"
Apologies to Vadym, who had tried to send the same thing to the list
but got blocked by moderation.
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107521
> Fixes: 726839459cb (au
From: "vadym.shovkoplias"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107521
Fixes: 726839459cb (autotools: Derive xkb configuration from xkbcomp.pc)
Signed-off-by: vadym.shovkoplias
---
configure.ac | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
On Tue, 2018-08-07 at 12:03 -0400, Adam Jackson wrote:
> We're not seriously maintaining this tool, we should stop pretending.
>
> Signed-off-by: Adam Jackson
Merged (and archived the project):
remote: remote: I: patch #243108 updated using rev
2aaa5d75f1b92a5383af676dbd7f099
We're not seriously maintaining this tool, we should stop pretending.
Signed-off-by: Adam Jackson
---
README | 27 +--
1 file changed, 5 insertions(+), 22 deletions(-)
diff --git a/README b/README
index 825d09e..f60d34f 100644
--- a/README
+++ b/README
@@ -3,26 +3,9
On Thu, 2018-08-02 at 15:22 +1000, Peter Hutterer wrote:
> On Wed, Aug 01, 2018 at 01:49:54PM -0700, Eric Anholt wrote:
> > Signed-off-by: Eric Anholt
>
> series Reviewed-by: Peter Hutterer
4/6 doesn't go too far enough, but this all looks good. Merged, thanks:
remote: remote: I: patch
On Thu, 2018-08-02 at 10:47 +0200, Michel Dänzer wrote:
> On 2018-08-01 08:10 PM, GitLab Mirror wrote:
> > New branch 'server-1.20-branch' available with the following commits:
>
> I'd like to nominate https://patchwork.freedesktop.org/patch/232490/ for
> 1.20.1 as well.
Hrargh. That patch
On Wed, 2018-08-01 at 14:38 +0200, Guillem Jover wrote:
> It would be nice if the xorg.modules (from modular) got updated too, so
> that some of this could be automated locally. :)
My goodness, we have written this down so many slightly different ways.
I've pushed some updates that I hope are
On Tue, 2018-07-31 at 11:53 +1000, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
> ---
> README | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Reviewed-by: Adam Jackson
And a pre-emptive r-b for the same change to every other repo, I
suppose. I can script tha
On Thu, 2018-07-26 at 12:25 +0100, Alan Hourihane wrote:
> Anyone tried just doing this recently
>
> xmodmap -pke > /tmp/keydump
> xmodmap /tmp/keydump
>
> And watch the Xserver hang for quite some time.
Seems to be nearly instantaneous against an Xvfb, but did cause a
noticable hiccup with
If you want to follow anything I'm working on, follow it here:
https://gitlab.freedesktop.org/ajax/xserver/
I'll be using merge requests under that repo to track the progress of
my own development branches, and issues to track known defects that
someone should work on. I won't be looking at
On Thu, 2018-07-19 at 14:38 +0200, Stefan Dirsch wrote:
> From: Takashi Iwai
>
> The recent rewrite of modesetting driver broke the 24bpp support.
> As typically found on cirrus KMS, it leads to a blank screen, spewing
> the error like:
> failed to add fb -22
> (EE) modeset(0): failed to set
On Wed, 2018-07-25 at 16:33 +0200, Olivier Fourdan wrote:
> glamor_fds_from_pixmap() will bail out early if DRI3 is not enabled,
> unfortunately Xwayland's glamor code would not set it as enabled which
> would lead to blank pixmaps when using texture from pixmap.
>
> Make sure to mark DRI3 as
On Thu, 2018-07-19 at 09:18 +0200, Olivier Fourdan wrote:
> Hi,
>
> On Mon, Jul 16, 2018 at 10:47 AM Simon Ser wrote:
> >
> Reviewed-by: Olivier Fourdan
Merged, thanks:
remote: remote: I: patch #238455 updated using rev
ce2dde9ed0243a18ae18af0879134f7c1afbd700.
remote: remote: I: 1
Keep the pixmap at unmap, always try to realize backing store, always
mark them when marking, and update paintable when backed.
Signed-off-by: Adam Jackson
---
composite/compalloc.c | 2 +-
composite/compinit.c | 24 +++--
composite/compint.h| 8 ++
composite
Signed-off-by: Adam Jackson
---
dix/window.c | 69
1 file changed, 32 insertions(+), 37 deletions(-)
diff --git a/dix/window.c b/dix/window.c
index ea3920c869..55290577d9 100644
--- a/dix/window.c
+++ b/dix/window.c
@@ -1589,7 +1589,7
Signed-off-by: Adam Jackson
---
mi/miwindow.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/mi/miwindow.c b/mi/miwindow.c
index 39c279e184..1b910d9bea 100644
--- a/mi/miwindow.c
+++ b/mi/miwindow.c
@@ -151,7 +151,7 @@ miMarkOverlappedWindows
---
dix/window.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dix/window.c b/dix/window.c
index 55290577d9..34bed93d93 100644
--- a/dix/window.c
+++ b/dix/window.c
@@ -2870,7 +2870,7 @@ UnmapWindow(WindowPtr pWin, Bool fromConfigure)
if (SubStrSend(pWin, pParent))
Signed-off-by: Adam Jackson
---
mi/mibitblt.c | 4 ++--
mi/micopy.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/mi/mibitblt.c b/mi/mibitblt.c
index 2de5bf8fd5..8d70e5494e 100644
--- a/mi/mibitblt.c
+++ b/mi/mibitblt.c
@@ -92,9 +92,9 @@ miCopyArea(DrawablePtr
Signed-off-by: Adam Jackson
---
mi/mivaltree.c | 108 ++---
1 file changed, 58 insertions(+), 50 deletions(-)
diff --git a/mi/mivaltree.c b/mi/mivaltree.c
index ea6889fdc0..f47cfa4571 100644
--- a/mi/mivaltree.c
+++ b/mi/mivaltree.c
@@ -164,14 +164,16
A paintable window is a window whose pixels are (potentially) modifiable
by rendering commands. Right now that just means the same thing as
viewable; it will soon also include unmapped windows with backing store
set to Always.
v2:
Set paintable in dix not ddx (Keith Packard)
Signed-off-by: Adam
This is a resend of a series I wrote forever ago and nobody dared
review. It probably needs some additional review and rethinking, but it
definitely shouldn't keep languishing on my hard drive.
The core issue is that Always windows need to have their pixels
allocated before the window is ever
On Mon, 2018-07-23 at 11:23 -0400, Adam Jackson wrote:
> Nobody did, so, this is done now.
>
> My earlier assertion about the git url not being changed is only true
> for pulls. For pushes, you will indeed need to update the remote to the
> new URL:
>
> $ git remote s
On Mon, 2018-07-09 at 14:30 -0400, Adam Jackson wrote:
> Currently the xorg group in gitlab is derived from the pre-existing
> freedesktop LDAP group. This is a bit excessive, there's over 250
> people in the group in total and not even a fifth of those are
> regularly active. If
On Mon, 2017-01-02 at 14:42 -0500, Adam Jackson wrote:
> On Thu, 2016-12-22 at 15:41 +0100, Stefan Agner wrote:
> > When setting DefaultDepth to 16 in the Screen section, the current
> > code requests a 32 bpp framebuffer, however the X-Server seems to
> > assumes 16 bpp.
On Mon, 2018-07-02 at 10:23 -0700, Keith Packard wrote:
> For the first step, I'd like to propose moving the x server git
> repository to gitlab in the coming week, with the switch-over happening
> on the morning of July 9.
This is now done:
https://gitlab.freedesktop.org/xorg/xserver
The old
On Fri, 2018-06-22 at 12:49 -0400, Lyude Paul wrote:
> Currently our meson.build just makes the assumption that the libc is
> going to provide RPC functions. This doesn't actually seem to be the
> case on Fedora, which causes compilation to fail unexpectedly:
>
>
On Wed, 2018-06-27 at 10:41 +0100, Daniel Stone wrote:
> Hi,
>
> On Wed, 27 Jun 2018 at 00:35, Keith Packard wrote:
> > @@ -3251,6 +3251,9 @@ drmmode_create_lease(RRLeasePtr lease, int *fd)
> >
> > nobjects = ncrtc + noutput;
> >
> > +if (ms->atomic_modeset)
> > +nobjects +=
On Thu, 2018-06-28 at 11:45 -0700, Keith Packard wrote:
> Before DIX structures are allocated for crtcs and outputs, we don't
> want to call DIX randr code with NULL pointers. This can happen if the
> driver sets video modes early in server initialization, which Nouveau
> does in zaphod mode.
>
>
On Mon, 2018-07-02 at 10:23 -0700, Keith Packard wrote:
> Adam Jackson writes:
>
> > I'd like us to start moving repos and bug tracking into gitlab.
>
> I would also like to get to a merge-request model at some
> point. However, I think we can take this in stages and star
On Fri, 2018-06-29 at 09:44 +0200, Laurent Carlier wrote:
> You've forgotten the gitlab repo
I have a (non-automatic) personal mirror on gitlab, but we've not
properly moved yet. If you're interested in following that progress,
see:
1 - 100 of 3179 matches
Mail list logo
