subscribe to xorg. It
looks like the xcb thread got sidetracked by a discussion of native
usage of XCB, and failed to address the original bug. Sorry about
that.
I'll follow up in the new thread you just started.
- Josh Triplett
___
xorg-devel
appropriate dbus call. You might check with the
xdg-utils developers about creating a desktop-independent xdg-logout
or similar command.
Hope that helps,
Josh Triplett
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg
if the initial attempt with an undefined
protocol fails. Implementing this logic somewhere common to the Xtrans
and XCB code paths makes sense. However, I don't think a fallback to
TCP in XCB makes sense, because then we might need to add other
platform-specific local fallbacks for other platforms.
- Josh
On Thu, Apr 29, 2010 at 03:12:43PM -0700, Alan Coopersmith wrote:
Josh Triplett wrote:
I find it quite dubious that real applications expect DISPLAY=:0 to
connect to TCP. It certainly violates the principle of least surprise.
But it's what the Xlib standard spec has always required. When
/libxcb master look 1.8.1 worthy, so perhaps
we can push this one into the mix and get a 1.8.1 this week.
Sounds good to me, if the xcb folks are ok with it.
Seems entirely sensible.
- Josh Triplett
___
xorg-devel@lists.x.org: X.Org development
-ReleaseNotes.html#Future_Removals
Do I need to explicitly give their names to make it clearer?
Yes, I think naming them would help, as well as naming the Xorg drivers
that replace them (dummy and nested).
- Josh Triplett
___
xorg-devel@lists.x.org
-dpi option, a DPI setting
in their graphical enironment, or an alternate scaling mechanism
provided by their environment.
- Josh Triplett
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http
XF86BIGFONT
extension]),XF86BIGFONT=no)
AC_SUBST(BIGFONT_CFLAGS)
AC_SUBST(BIGFONT_LIBS)
fi
- Josh Triplett
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg
it, and
the closer we get to a model in which only people who have ancient
programs that still use libX11 bother maintaining it. :)
- Josh Triplett
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org
one, add filters that peel off events into those queues (which XCB will
automatically apply as events arrive), and then read the next event from
a queue.
- Josh Triplett
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives
enough to go ahead and merge this.
- Josh Triplett
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
On Wed, Nov 06, 2013 at 09:25:40PM -0500, Peter Harris wrote:
On 2013-11-06 19:55, Josh Triplett wrote:
On Wed, Nov 06, 2013 at 02:34:03PM -0500, Peter Harris wrote:
On 2013-11-05 19:41, Keith Packard wrote:
This allows apps to peel off certain XGE events into separate queues
for custom
On Wed, Nov 06, 2013 at 06:39:19PM -0800, Keith Packard wrote:
Josh Triplett j...@joshtriplett.org writes:
The last time that Jamey and I spoke about this, we agreed that this
type of mechanism would be required to make GL work, and that there's
really no other way to support it. However
On Wed, Nov 06, 2013 at 07:45:39PM -0800, Keith Packard wrote:
Many system headers have warnings when compiled with this flag.
Signed-off-by: Keith Packard kei...@keithp.com
In theory, GCC should never be warning about things from system headers
unless asked to...
configure.ac | 2 +-
1
for an application to link with
libX11-xcb and with an older version of libX11 that does not have the
xcb field (and doesn't use libxcb underneath).
- Josh Triplett
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info
understand it, you only need util-macros
installed when building from git or otherwise autoreconfing, not when
building from a make dist tarball, right? Given that, I don't see any
harm in using it rather than reinventing it.
- Josh Triplett
___
xorg-devel
Xlib, and thus between
the two of them all X clients).
- Josh Triplett
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
that in from the start seems
preferable, rather than adding it after first constructing an
all-data-at-once API.
- Josh Triplett
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman
first constructing an
all-data-at-once API.
- Josh Triplett
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
On February 16, 2019 6:03:36 AM PST, Daniel Stone wrote:
>Hi all,
>As has been pretty well documented, I'd like to migrate XCB to GitLab
>to join the rest of fd.o and X.Org (apart from the kernel and Mesa).
>
>Whilst cgit/anongit would remain as mirrors, they would be read-only;
>the sole push
On Thu, Sep 29, 2022 at 05:45:28PM +0200, Uli Schlachter wrote:
> Hi,
>
> Am 29.09.22 um 06:27 schrieb Keith Packard:
> > Alan Coopersmith writes:
> >
> > > Does anyone disagree?
> >
> > Yeah, synchronizing with xcb seems 'obviously right. The only question
> > I've got is that in 2022, should
21 matches
Mail list logo
