Hi,
Selecting for XI2 events will disable core input events from being sent to
your client. This is to prevent XI2-enabled clients from getting duplicate
events and not knowing which to filter out. You need to select for
XI_FocusIn / XI_FocusOut events instead of using the core input events.
On
How is this different from unredirection? mutter / gnome-shell currently
doesn't unredirect windowed windows, but there's no reason it couldn't --
it just needs to be able to handle the case where it's unredirecting the
client window rather than the parent frame window.
On Fri, Feb 2, 2018 at 5:43
Should also mention that it also adds a strdup -- I feel that the code
calling this might conditionally free. Would be nice to double-check
callers.
On Wed, Sep 23, 2015 at 1:58 AM, Thomas Klausner wrote:
> From: Christos Zoulas
>
> Signed-off-by: Thomas Klausner
> ---
> src/util.c | 4 ++--
>
&name[1]);
> } else {
> (void) sprintf (newname, "%s/%s", Home, &name[1]);
> }
>
> return newname;
> }
>
> So in other words, now the function is consistent in returning a
> malloc()ed string when it succeeds.
> Thomas
>
> On W
On Sun, Oct 18, 2015 at 7:59 PM, Peter Hutterer
wrote:
> cookie->serial is an Xlib contoction, provided by _XSetLastRequestRead(). This
I assume this is meant to read "in->sequenceNumber is an Xlib
concoction"? Otherwise, it doesn't make sense.
> serial may be different to the raw serial number
error handler, since our driver re-opens the
Display in our own code, but a better approach might be TLS storage for
the global handler.
Signed-off-by: Jasper St. Pierre
---
include/X11/Xlib.h| 4
include/X11/Xlibint.h | 3 +++
src/ErrHndlr.c| 15 +++
src/Xlib
Should we just unconditionally enable xshmfence? Are there any OSes we
care about that can't implement a fence primitive?
On Sun, Nov 15, 2015 at 8:59 AM, Mark Kettenis wrote:
> Currently glamor hits an assertion on systems that don't have
> xshmfence. This happens when the glamor code calls
> m
a library -- this code runs in a different thread, and
we had issues where we overwrite another thread's error handler (in my
case, the two threads were using different Displays, as they should).
On Sun, Nov 15, 2015 at 11:56 PM, Keith Packard wrote:
> "Jasper St. Pierre" writes:
driver and this is where I gave up
and started on the Xlib solution.
On Mon, Nov 16, 2015 at 12:39 PM, Uli Schlachter wrote:
> Am 16.11.2015 um 18:06 schrieb Jasper St. Pierre:
> [...]
>> We currently use a behavior like:
>>
>> SetErrorHandler();
>>
abServer, but that's a bit weightier.
On Mon, Nov 16, 2015 at 1:11 PM, Adam Jackson wrote:
> On Fri, 2015-11-13 at 15:24 -0800, Jasper St. Pierre wrote:
>> Writing error-safe code that uses Xlib is too obnoxious, and using XCB
>> is tedious and not performant, as we can't
ating the new one
Cc: Adam Jackson
Signed-off-by: Jasper St. Pierre
---
composite/compalloc.c | 113 ++
1 file changed, 67 insertions(+), 46 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index 8daded0..06b54e9 100644
The only currently supported mechanism for using hardware overlays is
video planes through VDPAU / VA-API.
Xorg does not have any other supported mechanism for using hardware
overlays. Try looking at Wayland, which can have support for hardware
planes.
On Fri, Dec 25, 2015 at 8:29 AM, Cao Duc Qua
per.
> I plan to hook to QT embedded to make it use sprite plane buffer.
> I could make a tool (customized from modetest.c of libdrm) to render to
> sprite plane which are running in xorg.
>
> Thanks and Happy New Year.
> cdq
>
> On Wed, Dec 30, 2015 at 2:52 AM, Jasper St.
fer and modetest render to Sprite Plane
>
> It is a bug in kernel ?
>
> On Fri, Jan 1, 2016 at 5:04 AM, Jasper St. Pierre
> wrote:
>>
>> You can't. The only client that is allowed to do modesets, either on
>> planes or on the primary buffer, is the DRM master,
Let me copy/paste an internal email I wrote when I was investigating a
similar thing.
===
I've been investigating using the new Glamor acceleration layer for
our Xorg DDX.
For those not familiar with Glamor, basically, it implements X11
drawing primitives on top of OpenGL, so you can use your GP
I thought XV was simply about color conversion, it didn't handle video
display. I didn't Google it before replying, though.
On Tue, Jan 5, 2016 at 6:23 PM, Michel Dänzer wrote:
> On 30.12.2015 04:52, Jasper St. Pierre wrote:
>> The only currently supported mechanism for usin
I don't necessarily have an opinion either way, but do note that since
VGEM isn't here yet, this change will break using Xwayland under a
free VM. We should fall back to wl_shm in any case.
On Wed, Feb 10, 2016 at 9:16 AM, Daniel Stone wrote:
> On 10 February 2016 at 17:08, Kristian Høgsberg wro
As mentioned in the original email, it relies on this series:
https://lists.x.org/archives/xorg-devel/2016-February/048758.html
On Tue, Mar 8, 2016 at 9:41 AM, Adam Jackson wrote:
> On Wed, 2016-02-10 at 15:45 +1000, Dave Airlie wrote:
>
>> From: Dave Airlie
>>
>> This adds support using glamor
Can you give an example of when drmSetCursor2 would fail sometimes but
not always, enough to switch back and forth actively?
I'm not a huge fan of the patch because now errors could cause really
bizarre double-cursor, or no-cursor flickering, since there is no
guarantee that the swapover happens i
"Safe multi-line macros" have been suggested before, and turned down.
The C extension that gcc supports is statement expressions:
https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
On Sat, Mar 12, 2016 at 11:15 AM, walter harms wrote:
>
>
> Am 12.03.2016 19:43, schrieb Matt Turner:
>> On Sat
I think this should be done at the application level. If an
application is running, it has many other ways to fingerprint your
computer, including listing the files in your homedir, checking cpuid,
MAC address, etc. The issue here is that there is an application
platform that runs untrusted user co
ARMSOC isn't a well-written driver, basically. Is there a reason
you're not using modesetting if it works better for you?
On Thu, Mar 31, 2016 at 1:54 AM, Maxime Ripard
wrote:
> On Wed, Mar 23, 2016 at 10:17:05PM +0100, Maxime Ripard wrote:
>> Hi David, Marico,
>>
>> I've been developping a DRM/K
Hi,
Based on my reading of the spec, writing an ICCCM-compliant WM *requires*
blocking, since the behavior of an UnmapNotify depends on the attributes of
a window. We cannot process any X11 events while we are retrieving the
attributes of a mapped window inside MapRequest.
If we want to modify th
On Fri, Jul 11, 2014 at 1:54 PM, wrote:
> From: "Owen W. Taylor"
>
> Fix two places where the display was double locked when an API
> function chained to an implementation that also locks the display.
> ---
> src/XIAllowEvents.c | 6 +-
> src/XIPassiveGrab.c | 1 +
> 2 files changed, 2 inse
Reviewed-by: Jasper St. Pierre
On Sat, Jul 19, 2014 at 12:48 AM, Keith Packard wrote:
> I intended to use glFlush all along, but somehow managed to type
> glFinish instead. glFlush is sufficient (for a single-queue GPU) to
> ensure serialization between queued rendering in the X s
Why doesn't mesa allocate buffers in the same way for those chips, then?
Do you have any documentation about this?
On Thu, Sep 11, 2014 at 12:37 AM, Chris Wilson
wrote:
> On Wed, Sep 10, 2014 at 02:09:07PM -0700, Keith Packard wrote:
> > [PATCH 2/2] Correct BO allocation alignment
> >
> > This
08fabafac8b83ed0de90f9e27aa4b67f604b7e58:
xwayland: Snap damage reports to the bounding box (2014-09-11 21:47:31
-0600)
Adam Jackson (1):
xwayland: Snap damage reports to the bounding box
Jasper St. Pierre (2):
xwayland-input: Fix a
Looks good.
Reviewed-by: Jasper St. Pierre
On Sun, Sep 14, 2014 at 2:09 PM, Alan Coopersmith <
alan.coopersm...@oracle.com> wrote:
> Reported-by: Jasper St. Pierre
> Signed-off-by: Alan Coopersmith
> ---
> specs/ice.xml | 10 +-
> 1 file changed, 5 inser
Why would xeyes generate a large number of rectangles in a composited
environment? Are you talking about the initial expose?
On Thu, Sep 18, 2014 at 4:49 PM, Keith Packard wrote:
> Adam Jackson writes:
>
> > In attempting to get the Always mode of backing store working again, I
> > felt the urg
.
That doesn't sound like it would be too much traffic, and any machine could
handle that nowadays.
On Mon, Sep 22, 2014 at 1:13 PM, Keith Packard wrote:
> "Jasper St. Pierre" writes:
>
> > Why would xeyes generate a large number of rectangles in a composited
> >
How old? O_CLOEXEC is part of the 2008 POSIX specification. I really
wouldn't like to build on anything older than that... :(
On Mon, Sep 22, 2014 at 1:24 PM, Aaron Plattner
wrote:
> Old versions of Linux don't support O_CLOEXEC, so rather than failing to
> build,
> allow building without O_CLOE
Seems to exist to me:
http://cgit.freedesktop.org/xorg/driver/xf86-video-sis/
On Mon, Sep 22, 2014 at 9:50 PM, Felix Miata wrote:
> xorg-x11-drv-sis seems to have disappeared. Did that happen on purpose? It
> still exists as a selelection in Bugzilla. Xorg is looking for sis module
> but
> cann
On Tue, Sep 23, 2014 at 12:32 PM, Adam Jackson wrote:
> Signed-off-by: Adam Jackson
> ---
> composite/compinit.c | 4 ++--
> dix/window.c | 2 +-
> include/windowstr.h | 2 +-
> mi/miexpose.c| 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/composite/c
I sort of like "slide" because it gives the impression that we copy the
framebuffer contents if the size of the window hasn't changed. That said,
if we want to change this, we should change the name of the slot too.
Reviewed-by: Jasper St. Pierre
On Tue, Sep 23, 2014 at 12:32 P
I don't believe a driver is the correct thing to do. Xorg, in many places,
assumes it's on raw hardware and does things like modesetting and VT
switching, which obviously won't work in a nested environment.
Additionally, I think the Xorg maintainers think that less drivers is
better -- the modeset
No? He removed the brace so it's a one-line if body.
On Mon, Oct 27, 2014 at 4:34 PM, Keith Packard wrote:
> Adam Jackson writes:
>
> > No functional change.
> >
> > Signed-off-by: Adam Jackson
> > ---
> > composite/compinit.c | 27 ---
> > 1 file changed, 16 insertion
Reviewed-by: Jasper St. Pierre
On Tue, Oct 28, 2014 at 3:26 AM, Christophe Fergeau
wrote:
> The correct name is RRCrtcGetInfo.
>
> Signed-off-by: Christophe Fergeau
> ---
> randrproto.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff
This is causing build failures on GNOME Continuous:
http://build.gnome.org/continuous/buildmaster/builds/2014/12/31/4/build/log-xorg-xserver.txt
Reviewed-by: Jasper St. Pierre
On Tue, Dec 30, 2014 at 2:58 PM, Eric Anholt wrote:
> Kenneth Graunke writes:
>
> > present.c:
On Thu, Jan 1, 2015 at 10:31 PM, Keith Packard wrote:
> Rob Clark writes:
>
> > What about simply not using GL_QUADS for the normal GL paths? Is
> > using quads, vs tri's and a few extra vertices really going to be a
> > win on some other hw? If not, avoiding quads would be a big help for
> >
In the new KMS APIs, the legacy drmModeSetCursor ioctl actually waits
for a vblank after changing the cursor image before returning, meaning
that the X server, in attempting to hide the cursor before updating
its image, actually makes that hide *visible* for a full vblank.
It's unknown why the X s
The kernel might want this information during modesetting.
---
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 824500b..27b7fd8 100644
-
Fine by me. I actually stopped using vrefresh in my kernel driver and
instead started using drm_mode_vrefresh, so we can actually drop this patch.
On Thu, Jan 8, 2015 at 4:43 PM, Keith Packard wrote:
> "Jasper St. Pierre" writes:
>
> > Because several functions do not
On Thu, Jan 8, 2015 at 2:42 PM, Keith Packard wrote:
> "Jasper St. Pierre" writes:
>
> > The kernel might want this information during modesetting.
> > ---
> > hw/xfree86/drivers/modesetting/drmmode_display.c | 2 ++
> > 1 file changed, 2 insertions(+)
I mean, if you're going to break the ABI for this, can we fix it so that we
have one mode structure instead of three?
On Thu, Jan 8, 2015 at 4:56 PM, Keith Packard wrote:
> "Jasper St. Pierre" writes:
>
> > Fine by me. I actually stopped using vrefresh in my ke
Well, either MAX_LEVEL / BASE_LEVEL or MIN_FILTER / MAG_FILTER will fix it.
Basically, a texture is only considered complete [0] when all of its usable
mipmap levels have been defined. Either you set MAX_LEVEL to say it has 0
mipmaps (by default MAX_LEVEL is 1000), or you set MIN_FILTER / MAG_FILT
get right.
Patch, as-is, is Reviewed-by: Jasper St. Pierre
On Fri, Jan 9, 2015 at 6:20 PM, Jasper St. Pierre
wrote:
> Well, either MAX_LEVEL / BASE_LEVEL or MIN_FILTER / MAG_FILTER will fix it.
>
> Basically, a texture is only considered complete [0] when all of its
> usable mipmap le
Markus Wick, the gsoc student on glamor this year.
On Jan 9, 2015 8:16 PM, "Keith Packard" wrote:
> "Jasper St. Pierre" writes:
>
> > I guess I should follow up with that I don't really care how the patch
> ends
> > up or which six colors of the
What project is this for? There's no "src/common_init.c" in Xorg, of course.
On Fri, Feb 6, 2015 at 9:29 AM, Emil Velikov
wrote:
> From: Eero Tamminen
>
> "__linux__" is the POSIX define for checking for Linux OS, "linux" is
> deprecated and apparently not supported by Android.
>
> Besides corr
This makes sense.
Reviewed-by: Jasper St. Pierre
On Mon, Feb 9, 2015 at 1:56 PM, Emil Velikov
wrote:
> Would anyone have some input - apart from the missing libpciaccess
> prefix of course ?
> Fwiw src/common_interface.c already checks for __linux__, so this
> patch makes
"-background none" needs to be supported by the DDX to copy existing
framebuffer contents into the root window. What DDX are you using?
On Sun, Feb 8, 2015 at 10:37 PM, kirthika varadarajan <
kirthikai...@gmail.com> wrote:
> Hi All,
> From linux driver I am writing an image to video buffer.
>
>
Some toolkits implement comboboxes or menus or other things through
O-R windows, which aren't children of the focused window. In order to
properly get input on them during grab conditions, we need to trace the
whole input tree, not just the focused window down.
Signed-off-by: Jasper St. P
---
test/xi1/.gitignore | 1 +
1 file changed, 1 insertion(+)
create mode 100644 test/xi1/.gitignore
diff --git a/test/xi1/.gitignore b/test/xi1/.gitignore
new file mode 100644
index 000..c1b9024
--- /dev/null
+++ b/test/xi1/.gitignore
@@ -0,0 +1 @@
+protocol-xchangedevicecontrol
--
2.1.0
The guard window is supposed to be capturing input. That's the whole point.
We stack windows below the guard window when minimizing them so that input
won't go to them, but we can still show live-previews for them in Alt-Tab.
On Fri, Feb 20, 2015 at 4:57 AM, Daniel Stone wrote:
> Hi,
>
> On 20
}
> +#endif
> +/* convert to root coordinates */
> +x += xwl_seat->focus_window->window->drawable.x;
> +y += xwl_seat->focus_window->window->drawable.y;
> +sprite->spriteTraceGood = 1;
> return miSpriteTrace(sprite, x, y
d it fixes comboboxes and menus.
If somebody then wants to revert 73698d4, that's fine by me, so we
reduce the amount of API that DDXen have.
Signed-off-by: Jasper St. Pierre
---
hw/xwayland/xwayland-input.c | 34 --
hw/xwayland/xwayland.h | 1 -
2 files change
... Why does displayfd imply nolock? That seems strange to me. I consider
the .X0-lock files an API that we shouldn't break.
On Fri, Mar 20, 2015 at 7:02 AM, Hans de Goede wrote:
> Currently startx relies on /tmp/.X?-lock being present for automatically
> picking a free display number. This does
If a window has ForgetGravity in its bitGravity, that very likely
means it will repaint on the ConfigureNotify / Expose event, and thus
we don't have to copy the old pixmap into the new pixmap, we can simply
leave it blank.
Preventing this copy is super simple to do and a big win on small
devices
ff-by: Jasper St. Pierre
---
composite/compalloc.c | 109 +-
1 file changed, 63 insertions(+), 46 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index 8daded0..40bf873 100644
--- a/composite/compalloc.c
+++ b/composite/compal
"const" implies that the pointer is in static memory, and could easily
make people not free it after calling xf86DuplicateMode out of
confusion. Change it back to a "char *", and fix up callers to respect
that.
---
hw/xfree86/common/xf86Mode.c| 2 +-
hw/xfree86/common/xf86VidMode.c | 18 +
nts the compositor a correctly-sized, finished pixmap.
On Thu, Apr 23, 2015 at 2:13 PM, Aaron Plattner wrote:
> Does this cause flickering when resizing windows and the compositor reads
> the new window pixmap before the app has a chance to respond to the events?
>
>
> On 04/23/201
Are you sure that's the correct Xorg bug? Goes to something related to
x86emu for me.
On Tue, Apr 28, 2015 at 4:51 PM, Peter Hutterer
wrote:
> With a long entry in the man page to detail what this option does.
> Specifically, it's the xorg.conf equivalent to XSetPointerMapping(3), it
> doesn't do
(Resending from the email address I'm subscribed to, sorry for the noise)
I don't see how that's the case. The select() call should never block, see:
http://cgit.freedesktop.org/xorg/xserver/tree/os/connection.c#n1000
From select(2):
If both fields of the timeval structure are zero, then se
I don't see how that's the case. The select() call should never block, see:
http://cgit.freedesktop.org/xorg/xserver/tree/os/connection.c#n1000
>From select(2):
If both fields of the timeval structure are zero, then select() returns
immediately.
On Tue, May 12, 2015 at 7:18 PM, Michel Dänze
XFree crashes when passed NULL.
On Thu, May 21, 2015 at 6:11 AM, walter harms wrote:
>
>
> Am 21.05.2015 14:55, schrieb Eirik Byrkjeflot Anonsen:
>> Signed-off-by: Eirik Byrkjeflot Anonsen
>> ---
>> xprop.c | 10 --
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/x
Expecting anything atomic from X11 in the first place is a wrong assumption.
On Thu, May 21, 2015 at 6:18 AM, Marek Chalupa wrote:
> Hi,
>
> On Sat, May 16, 2015 at 7:38 AM, Dima Ryazanov wrote:
>>
>> Add the output to the list when it's created rather than when its
>> properties
>> change (as p
I thought I remembered something which tried to poke the pointer first
to make it crash if it was NULL, since freeing of a NULL pointer was
considered a bug.
On Thu, May 21, 2015 at 9:34 AM, Emil Velikov wrote:
> On 21 May 2015 at 17:21, Jasper St. Pierre wrote:
>> XFree crashes wh
This makes sense to me.
Reviewed-by: Jasper St. Pierre
On Mon, May 25, 2015 at 12:15 PM, Rui Matos wrote:
> In some extreme cases with animated cursors at a high frame rate we
> could end up filling the wl_display outgoing buffer and end up with
> wl_display_flush() failing.
>
&
I'm planning on removing this hook and just make compositors deal with
the fallout. Unfortunately, it hasn't been merged yet.
http://patchwork.freedesktop.org/patch/43021/
On Wed, May 27, 2015 at 9:42 AM, Carlos Garnacho wrote:
> For these, we must first lookup the DIX sequence from the Sprite,
I wonder if we should tell the Qt people about this so they can get
back on the fast path?
In any case, makes sense.
Reviewed-by: Jasper St. Pierre
On Wed, May 27, 2015 at 10:31 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> XRender defines this, GL really doesn't like it.
&g
Why not use -displayfd to get the display number to connect to? This
patch is still a good idea, I think, but it's not required.
On Wed, Jun 17, 2015 at 12:28 PM, Mike Blumenkrantz wrote:
> On Thu, 11 Jun 2015 16:54:36 -0400
> Mike Blumenkrantz wrote:
>
>> On Thu, 11 Jun 2015 12:37:10 -0700
>> A
For context, when we receive a MapNotify from the server, we have a
number of round-trips with the server.
First, there's the XGetWindowAttributes. It would be convenient to
have that along with the MapNotify, but not really a big deal.
We implement our own XCB-style async XGetWindowProperty (whi
One lets us submit all the requests in one go and get notified if an
error happens. The other requires us to synchronously ping-pong
to/from the server.
On Wed, Jun 17, 2015 at 5:06 PM, Peter Hutterer
wrote:
> On Wed, Jun 17, 2015 at 02:05:59PM -0700, Jasper St. Pierre wrote:
>> Fo
On Mon, Sep 23, 2013 at 8:55 AM, 小飞珑 <404962...@qq.com> wrote:
>
> I don't want to waste others' time. I mean: Are the fbCopyNtoN() called in
> UXA uxa/uxa-accel,c, and fbCopyArea() called in UXA uxa/uxa-unaccel.c,
> implemented in the file fb/fbcopy.c in Xorg ?
>
>
Yes.
> -- 原始邮
Yes, we have given up on portability to Cray systems. That's the only
system, as far as I know, that ever used all-bits-0 != nil pointers.
On Sat, Sep 28, 2013 at 1:22 AM, Mouse wrote:
> > Use calloc for the array of pointers to ensure pointers are cleared
> > out so we don't try to free garbag
Reviewed-by: Jasper St. Pierre
On Tue, Oct 29, 2013 at 12:09 PM, Adam Jackson wrote:
> Based on some bugzilla scraping I did around November 2012. Of xserver
> bugs in Red Hat bugzilla with an EQ size message in the log, the
> distribution looked like:
&
On Tue, Oct 29, 2013 at 9:55 PM, Alan Coopersmith <
alan.coopersm...@oracle.com> wrote:
> Signed-off-by: Alan Coopersmith
> ---
> src/FreeType/ftfuncs.c |4 +---
> src/FreeType/xttcap.c |3 +--
> src/fontfile/fontdir.c | 10 +++---
> 3 files changed, 5 insertions(+), 12 deletions(
Reviewed-by: Jasper St. Pierre
On Tue, Oct 29, 2013 at 9:55 PM, Alan Coopersmith <
alan.coopersm...@oracle.com> wrote:
> Missed in xalloc -> malloc etal conversion in 0cdc9b8f850342
>
> Signed-off-by: Alan Coopersmith
> ---
> src/FreeType/ftfuncs.c |4 ++--
Cool.
Reviewed-by: Jasper St. Pierre
On Tue, Oct 29, 2013 at 9:51 PM, Alan Coopersmith <
alan.coopersm...@oracle.com> wrote:
> Signed-off-by: Alan Coopersmith
> ---
> utils.c | 59
> ---
&
Reviewed-by: Jasper St. Pierre
On Tue, Oct 29, 2013 at 9:51 PM, Alan Coopersmith <
alan.coopersm...@oracle.com> wrote:
> Signed-off-by: Alan Coopersmith
> ---
> action.c |8
> action.h |4 ++--
> compat.c |2 +-
&
Reviewed-by: Jasper St. Pierre
On Tue, Oct 29, 2013 at 7:25 PM, Peter Hutterer wrote:
> 94ed0ba1b5043ad9fc33b42756af447d5ab15bbd moved backtracing into the DIX, so
> this comment is outdated. since no-one noticed and it's easier to just grep
> than update file references, remo
Reviewed-by: Jasper St. Pierre
On Tue, Oct 29, 2013 at 7:25 PM, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer
> ---
> os/backtrace.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/os/backtrace.c b/os/backtrace.c
> index 426f9b1..3
Reviewed-by: Jasper St. Pierre
On Tue, Oct 29, 2013 at 9:51 PM, Alan Coopersmith <
alan.coopersm...@oracle.com> wrote:
> Signed-off-by: Alan Coopersmith
> ---
> utils.h |9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/utils.h b/utils.h
> in
"almost identical"? Mind expanding on this?
On Tue, Oct 29, 2013 at 7:25 PM, Peter Hutterer wrote:
> The recent change to use elfutils made these conditions almost identical.
>
> Signed-off-by: Peter Hutterer
> ---
> os/backtrace.c | 29 +++--
> 1 file changed, 11 inser
I'm not a fan at all. This API is really bad compared to what's provided by
libbacktrace, which is super simple. This also seem to require callbacks
that have "Linux" in the name. Why are we trying to get rid of
libbacktrace, and what's the schedule for this?
On Tue, Oct 29, 2013 at 7:25 PM, Pete
You do know you can implement an asprintf-alike using vsnprintf, right?
On Tue, Oct 29, 2013 at 9:51 PM, Alan Coopersmith <
alan.coopersm...@oracle.com> wrote:
> Most were fixed length or length checked anyway, this just saves time
> doublechecking that. (A few could be replaced by asprintf, b
Sure, then:
Reviewed-by: Jasper St. Pierre
On Wed, Oct 30, 2013 at 12:21 AM, Alan Coopersmith <
alan.coopersm...@oracle.com> wrote:
> On 10/29/13 07:22 PM, Jasper St. Pierre wrote:
>
>> You do know you can implement an asprintf-alike using vsnprintf, right?
>>
>
&
; On Wed, 30 Oct 2013 03:13:28 +0100, Jasper St. Pierre wrote:
> > This API is really bad compared to what's provided by
> > libbacktrace, which is super simple.
>
> libbacktrace is not a real unwinder, it runs on top of libgcc backtrace()
> you
> currently use. Which is
Should you change (default: auto) ?
On Wed, Oct 30, 2013 at 6:26 PM, Adam Jackson wrote:
> DRI2 AIGLX was defaulting to 'auto', the tests for building the actual
> loader were checking for 'yes', whoops. This ought to be a check for
> the appropriate DRI2 protocol bits, but this is good enough
Reviewed-by: Jasper St. Pierre
On Thu, Nov 7, 2013 at 12:01 PM, Adam Jackson wrote:
> There's a --disable-present, so it'd be nice if it worked.
>
> Signed-off-by: Adam Jackson
> ---
> mi/miinitext.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
We want to make sure we don't write files to disk. /tmp on some systems is
backed by a disk, not tmpfs.
On Fri, Nov 8, 2013 at 2:53 AM, Mark Kettenis wrote:
> > From: Alan Coopersmith
> > Date: Thu, 7 Nov 2013 20:55:44 -0800
> >
> > Signed-off-by: Alan Coopersmith
> > ---
> > Makefile |9
The warnings are trying to prevent you from freeing a string constant and
having corrupt memory or double frees or worse. Casts are a *very* bad way
to work around the issue, and I'd highly recommend that if you want to
potentially free something, you use `char *`, not `const char *`.
On Mon, Nov
Reviewed-by: Jasper St. Pierre
On Wed, Dec 11, 2013 at 1:29 PM, Adam Jackson wrote:
> If you don't do this then the client libs on 64-bit machines see them as
> XIDs, which are 64-bit wide (sigh), which ruins the wire encoding and
> nothing works.
>
> Signed-
Reviewed-by: Jasper St. Pierre
On Thu, Dec 12, 2013 at 10:58 AM, Adam Jackson wrote:
> " is not the mate of ].
>
> Signed-off-by: Adam Jackson
> ---
> configure.ac | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configur
Reviewed-by: Jasper St. Pierre
On Fri, Dec 13, 2013 at 12:05 PM, Adam Jackson wrote:
> There's nothing to stop a client from sending these requests to screens
> without DRI3 support, and if they do, we'll crash. Let's not do that.
>
> Signed-off-by: Adam Jackson
So, I know this is existing practice, but it seems to me that building with
different protocol headers than what the server supports would only lead to
disaster.
Do we do this anywhere already?
On Fri, Dec 13, 2013 at 12:05 PM, Adam Jackson wrote:
> We want to advertise the version we implemen
OK then. Thanks for the explanation.
Reviewed-by: Jasper St. Pierre
On Fri, Dec 13, 2013 at 1:45 PM, Adam Jackson wrote:
> On Fri, 2013-12-13 at 13:13 -0500, Jasper St. Pierre wrote:
> > So, I know this is existing practice, but it seems to me that building
> > with dif
Reviewed-by: Jasper St. Pierre
On Fri, Dec 13, 2013 at 12:05 PM, Adam Jackson wrote:
> We want to advertise the version we implement, not the version the
> protocol headers happen to describe.
>
> Signed-off-by: Adam Jackson
> ---
> dri3/dri3_request.c | 5 +++--
&
Reviewed-by: Jasper St. Pierre
On Sat, Jan 4, 2014 at 2:47 AM, Alan Coopersmith <
alan.coopersm...@oracle.com> wrote:
> Left behind when 15e5eaf62897 removed support for building without XCB.
>
> Signed-off-by: Alan Coopersmith
> ---
>
Does FSmalloc do anything special, or is it just a wrapper for historical
reasons?
On Tue, Jan 7, 2014 at 7:02 PM, Alan Coopersmith <
alan.coopersm...@oracle.com> wrote:
> Signed-off-by: Alan Coopersmith
> ---
> src/FSOpenServ.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
>
Reviewed-by: Jasper St. Pierre
On Tue, Jan 7, 2014 at 7:02 PM, Alan Coopersmith <
alan.coopersm...@oracle.com> wrote:
> Solaris has:
> #define EWOULDBLOCK EAGAIN
> so checking (errno == EAGAIN || errno == EWOULDBLOCK) is overkill.
>
> This leads cppcheck 1.62 to co
1 - 100 of 199 matches
Mail list logo
