Re: Xwayland on demand (Re: [PATCH xwayland 3/3] xwayland: Handle the case of windows being realized before redirection)

Hi, Catching up on this thread. It's possible I missed something here, but here's my two cents. Right now, the Wayland compositor sets up a "dummy" socket for the X11 display. When a client connects, it launches Xwayland on-demand. I assume this socket handoff is done similar to the systemd

Re: WebKit failing to find GLXFBConfig, confusion around fbconfigs + swrast

On Mon, Aug 27, 2018 at 1:07 AM Daniel Drake wrote: > Hi, > > I'm looking at a strange issue which has taken me across WebKit, > glvnd, mesa and X, and has left me somewhat confused regarding if I've > found any real bugs here, or just expected behaviour (my graphics > knowledge doesn't go far

Re: A question about XCompositeRedirectSubwindows

On Wed, Jun 20, 2018 at 8:19 AM Adam Jackson wrote: > On Tue, 2018-06-19 at 17:35 -0700, Jasper St. Pierre wrote: > > > First off, there's a super high latency cost here. > > There is a latency cost, but I think it's worth being honest about it. > I'm on whatever iteration o

Re: A question about XCompositeRedirectSubwindows

things are "supposed to work". > A lot of those people are on this list. Or, if not here, on the wayland-devel list. I'm not one of them, but I feel I've worked on enough X-related things to understand how the system is put together. > Thanks! I think I might need it :P > > > On 19. jun

Re: A question about XCompositeRedirectSubwindows

e > this is impossible, and you should turn of input for the overlay, and > position the real window underneath in a "strategic position"... > > Also, is there any good documentation and/or tutorials around this > anywhere? > > /Egil > > On 19. juni 2018 08:42, Jasp

Re: A question about XCompositeRedirectSubwindows

Hi, What you're seeing here is a fun little side effect of composite. As you might be aware, unredirected X windows don't have any backing storage beyond the front buffer -- the full window contents are not really there. That means that when the X server first goes to redirect these windows, it

Re: Making Composite better for interactive apps

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

Re: NotifyGrab

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

Re: weird Xwayland and compositor deadlock issue [WAS: [PATCH xserver v2] xwayland: handle EAGAIN and EINTR gracefully]

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

Re: ARMSOC X11 plugin issues

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,

Re: Proposal for Anti-Keystroke Fingerprinting at the Display Server Level

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

Re: [PATCH:makedepend] Use do { ... } while(0) idiom to make debug() macro safer

"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

Re: [PATCH] modesetting: allow switching from software to hardware cursors.

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

Re: [PATCH] modesetting: add support for background none.

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

Re: [PATCH] xwayland: Use drm buffers for cursors if available

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,

Re: Use hardware sprite plane as overlay

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 <mic...@daenzer.net> wrote: > On 30.12.2015 04:52, Jasper St. Pierre wrote: >> The only currently supported mech

Re: Enable Glamor EGL with Mali

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

Re: Use hardware sprite plane as overlay

to > primary buffer and modetest render to Sprite Plane > > It is a bug in kernel ? > > On Fri, Jan 1, 2016 at 5:04 AM, Jasper St. Pierre <jstpie...@mecheye.net> > wrote: >> >> You can't. The only client that is allowed to do modesets, either on >> plan

Re: Use hardware sprite plane as overlay

wrote: > Thanks Jasper. > 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

Re: Use hardware sprite plane as overlay

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

[PATCH] composite: Don't bother copying the pixmap for ForgetGravity windows (v3)

the new one Cc: Adam Jackson <a...@redhat.com> Signed-off-by: Jasper St. Pierre <jstpie...@mecheye.net> --- composite/compalloc.c | 113 ++ 1 file changed, 67 insertions(+), 46 deletions(-) diff --git a/composite/compalloc.c b/composite

Re: [PATCH xlib] Add support for a display-specific error handler

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 <kei...@keithp.com> wrote: > "Jasper St. Pierre" <jstpie...@mecheye.net> writes: >

Re: [PATCH xlib] Add support for a display-specific error handler

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 <psyc...@znc.in> wrote: > Am 16.11.2015 um 18:06 schrieb Jasper St. Pierre: > [...] >> We currently use a behavior like: >> >> SetE

[PATCH xlib] Add support for a display-specific error handler

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 <jstpie...@mecheye.net> --- include/X11/Xlib.h| 4 include/X11/Xlibint.h | 3 +++ src/ErrHndlr.c

Re: [PATCH libXi] Don't use raw serial numbers in XIEvents

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

Re: [PATCH:twm] Add some const.

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

Re: [PATCH:twm] Add some const.

Home, [1]); > } else { > (void) sprintf (newname, "%s/%s", Home, [1]); > } > > return newname; > } > > So in other words, now the function is consistent in returning a > malloc()ed string when it succeeds. > Thomas > > On Wed, Sep

Re: [Xcb] [PATCH Xlib 1/3] Hoist most of _XConnectXCB into XOpenDisplay, and simplify

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 zm...@samsung.com wrote: On Thu, 11 Jun 2015 16:54:36 -0400 Mike Blumenkrantz zm...@samsung.com wrote: On Thu,

Re: Nested procedures into X12

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 peter.hutte...@who-t.net wrote: On Wed, Jun 17, 2015 at 02:05:59PM -0700, Jasper St. Pierre

Re: Nested procedures into X12

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

Re: [PATCH] glamor: don't do render ops with matching source/dest

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 jstpie...@mecheye.net On Wed, May 27, 2015 at 10:31 PM, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com XRender

Re: [PATCH xwayland 4/4] xwayland: Make the XYToWindowProc implementation aware of touchpoints

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 carl...@gnome.org wrote: For these, we must first lookup the DIX sequence

Re: [PATCH xwayland] xwayland: Throttle our cursor surface updates with a frame callback

This makes sense to me. Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net On Mon, May 25, 2015 at 12:15 PM, Rui Matos tiagoma...@gmail.com 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

Re: [PATCH v2 2/4] Free the data returned by XGetWindowProperty()

XFree crashes when passed NULL. On Thu, May 21, 2015 at 6:11 AM, walter harms wha...@bfs.de wrote: Am 21.05.2015 14:55, schrieb Eirik Byrkjeflot Anonsen: Signed-off-by: Eirik Byrkjeflot Anonsen ei...@eirikba.org --- xprop.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-)

Re: [PATCH v2 1/3] xwayland: Fix the addition and removal of outputs

Expecting anything atomic from X11 in the first place is a wrong assumption. On Thu, May 21, 2015 at 6:18 AM, Marek Chalupa mchqwe...@gmail.com wrote: Hi, On Sat, May 16, 2015 at 7:38 AM, Dima Ryazanov d...@gmail.com wrote: Add the output to the list when it's created rather than when its

Re: [PATCH] Allow system call restarts upon signal interruption

(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

Re: [PATCH] Allow system call restarts upon signal interruption

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

Re: [PATCH xf86-input-libinput 4/4] Add option ButtonMapping (#9206)

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 peter.hutte...@who-t.net wrote: With a long entry in the man page to detail what this option does. Specifically, it's the xorg.conf equivalent to

[PATCH] composite: Don't bother copying the pixmap for ForgetGravity windows (v2)

Signed-off-by: Jasper St. Pierre jstpie...@mecheye.net --- 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

[PATCH] xf86Mode: Don't make the mode name a const char *

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

Re: [PATCH] composite: Don't bother copying the pixmap for ForgetGravity windows (v2)

a correctly-sized, finished pixmap. On Thu, Apr 23, 2015 at 2:13 PM, Aaron Plattner aplatt...@nvidia.com 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/2015 01:24 PM, Jasper St. Pierre

[PATCH] composite: Don't bother copying the pixmap for ForgetGravity windows

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

Re: [PATCH xinit 1/2] startx: Fix startx picking an already used display number when -nolock is used

... 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 hdego...@redhat.com wrote: Currently startx relies on /tmp/.X?-lock being present for automatically picking a free display

[PATCH] xwayland-input: Remove our XYToWindow handler

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 jstpie...@mecheye.net --- hw/xwayland/xwayland-input.c | 34 -- hw/xwayland/xwayland.h | 1 - 2 files

Re: [PATCH] xwayland-input: Don't assume all input is children of the focused window

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 dan...@fooishbar.org

Re: [PATCH] xwayland-input: Don't assume all input is children of the focused window

. Cheers, Olivier On 18/02/15 21:41, Jasper St. Pierre wrote: 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

[PATCH] xwayland-input: Don't assume all input is children of the focused window

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. Pierre

[PATCH] test/xi1: Update .gitignore

--- 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

Re: [PATCH 4/4] Check for __linux__ instead of linux during compilation

This makes sense. Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net On Mon, Feb 9, 2015 at 1:56 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Would anyone have some input - apart from the missing libpciaccess prefix of course ? Fwiw src/common_interface.c already checks for __linux__

Re: Start Xorg with background image

-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. When

Re: [PATCH 4/4] Check for __linux__ instead of linux during compilation

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 emil.l.veli...@gmail.com wrote: From: Eero Tamminen eero.t.tammi...@intel.com __linux__ is the POSIX define for checking for Linux OS, linux is deprecated and apparently

Re: 1.17 status and schedule

. Patch, as-is, is Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net On Fri, Jan 9, 2015 at 6:20 PM, Jasper St. Pierre jstpie...@mecheye.net 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

Re: 1.17 status and schedule

Markus Wick, the gsoc student on glamor this year. On Jan 9, 2015 8:16 PM, Keith Packard kei...@keithp.com wrote: Jasper St. Pierre jstpie...@mecheye.net 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 bikeshed we end up

Re: 1.17 status and schedule

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 /

Re: [PATCH] modesetting: Copy over VRefresh to/from KMS modes

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 kei...@keithp.com wrote: Jasper St. Pierre jstpie...@mecheye.net writes: Fine by me. I actually stopped using vrefresh in my

Re: [PATCH] modesetting: Copy over VRefresh to/from KMS modes

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 kei...@keithp.com wrote: Jasper St. Pierre jstpie...@mecheye.net writes: Because several functions

Re: [PATCH] modesetting: Copy over VRefresh to/from KMS modes

On Thu, Jan 8, 2015 at 2:42 PM, Keith Packard kei...@keithp.com wrote: Jasper St. Pierre jstpie...@mecheye.net writes: The kernel might want this information during modesetting. --- hw/xfree86/drivers/modesetting/drmmode_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH] modesetting: Copy over VRefresh to/from KMS modes

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

[PATCH] modesetting: Update the cursor without hiding it

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

Re: misc fixes for VC4

On Thu, Jan 1, 2015 at 10:31 PM, Keith Packard kei...@keithp.com wrote: Rob Clark robdcl...@gmail.com 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

Re: [PATCH] modesetting: Fix build with --disable-glamor.

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 jstpie...@mecheye.net On Tue, Dec 30, 2014 at 2:58 PM, Eric Anholt e...@anholt.net wrote: Kenneth Graunke kenn

Re: [randrproto] spec: Fix RRCrtcGetModes typo

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net On Tue, Oct 28, 2014 at 3:26 AM, Christophe Fergeau cferg...@redhat.com wrote: The correct name is RRCrtcGetInfo. Signed-off-by: Christophe Fergeau cferg...@redhat.com --- randrproto.txt | 4 ++-- 1 file changed, 2 insertions(+), 2

Re: [PATCH 33/37] composite: Factor out backing store transition

No? He removed the brace so it's a one-line if body. On Mon, Oct 27, 2014 at 4:34 PM, Keith Packard kei...@keithp.com wrote: Adam Jackson a...@redhat.com writes: No functional change. Signed-off-by: Adam Jackson a...@redhat.com --- composite/compinit.c | 27

Re: Writing a new driver for nested Xorg servers based on Xephyr code

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

Re: F21/F22: xorg-x11-drv: which for SiS?

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 mrma...@earthlink.net 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

Re: [PATCH 13/18] dix: Lower backStorage to a bit instead of a pointer

On Tue, Sep 23, 2014 at 12:32 PM, Adam Jackson a...@redhat.com wrote: Signed-off-by: Adam Jackson a...@redhat.com --- composite/compinit.c | 4 ++-- dix/window.c | 2 +- include/windowstr.h | 2 +- mi/miexpose.c| 2 +- 4 files changed, 5 insertions(+), 5 deletions(-)

Re: [PATCH 17/18] mi: miSlideAndSizeWindow - miResizeWindow

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 jstpie...@mecheye.net On Tue, Sep 23, 2014 at 12:32

Re: [PATCH 00/11] Misc window exposure/validation cleanups

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 kei...@keithp.com wrote: Jasper St. Pierre jstpie...@mecheye.net writes: Why would xeyes generate a large number of rectangles in a composited environment

Re: [PATCH libpciaccess] Allow building without O_CLOEXEC

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 aplatt...@nvidia.com wrote: Old versions of Linux don't support O_CLOEXEC, so rather than failing to build, allow

Re: [PATCH 00/11] Misc window exposure/validation cleanups

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 kei...@keithp.com wrote: Adam Jackson a...@redhat.com writes: In attempting to get the Always mode of backing store

Re: [PATCH:libICE] spec: Convert troff \*Q..\*U to DocBook quote.../quote

Looks good. Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net On Sun, Sep 14, 2014 at 2:09 PM, Alan Coopersmith alan.coopersm...@oracle.com wrote: Reported-by: Jasper St. Pierre jstpie...@mecheye.net Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com --- specs/ice.xml | 10

Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA

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 ch...@chris-wilson.co.uk wrote: On Wed, Sep 10, 2014 at 02:09:07PM -0700, Keith Packard wrote: [PATCH 2/2] Correct BO allocation

[PULL] hw/xwayland patches

to 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

Re: [PATCH] glamor: sync_fence_set_triggered should use glFlush, not glFinish

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net On Sat, Jul 19, 2014 at 12:48 AM, Keith Packard kei...@keithp.com 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

Re: [PATCH] Fix locking bugs with XIAllowTouchEvents() and XIUngrabTouchBegin()

On Fri, Jul 11, 2014 at 1:54 PM, otay...@redhat.com wrote: From: Owen W. Taylor otay...@fishsoup.net 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 |

Re: [PATCH libXi 2/2] XIPassiveGrab: Fix completely broken locking in XIGrabTouchBegin

_XiCheckExtInit already unlocks the display on error. Yes, it's terrible. On Wed, Jul 9, 2014 at 3:23 AM, walter harms wha...@bfs.de wrote: Am 08.07.2014 23:01, schrieb Jasper St. Pierre: _XIPassiveGrabDevice calls LockDisplay as the first thing it does. That means that it expects

Re: [PATCH libXi 2/2] XIPassiveGrab: Fix completely broken locking in XIGrabTouchBegin

But all the other existing code that uses _XiCheckExtInit expects it to unlock on error, but not on success. Peter wrote this code, though, so I'll let him have the final say. On Wed, Jul 9, 2014 at 6:31 AM, walter harms wha...@bfs.de wrote: Am 09.07.2014 12:23, schrieb Jasper St. Pierre

[PATCH libXi 2/2] XIPassiveGrab: Fix completely broken locking in XIGrabTouchBegin

_XIPassiveGrabDevice calls LockDisplay as the first thing it does. That means that it expects the display to be unlocked. XIGrabTouchBegin locks the display to check for the XI extension, and then never unlocks it. Effectively, this meant that anybody that called XIGrabTouchBegin after

[PATCH libXi 1/2] XIPassiveGrab: Fix display locking inside _XIPassiveGrabDevice for error paths

The code here before would just leave the display locked on error, which all sorts of broken. --- src/XIPassiveGrab.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/XIPassiveGrab.c b/src/XIPassiveGrab.c index baadccb..f3a9924 100644 ---

Re: [PATCH 2/2] xwayland: Implement throttling for surfaces based on the frame event

On Wed, Jul 2, 2014 at 2:33 PM, Adam Jackson a...@nwnk.net wrote: On Mon, 2014-06-30 at 20:29 -0400, Jasper St. Pierre wrote: This implements simple throttling that keeps us to one attach per frame. There isn't really an active performance benefit, since the buffers will be redrawn only

[PATCH 2/2] xwayland: Implement throttling for surfaces based on the frame event

This implements simple throttling that keeps us to one attach per frame. There isn't really an active performance benefit, since the buffers will be redrawn only once per frame anyway, but it does cut down on the chatty network traffic. Since the Wayland sockets might fill up as well, the cut down

[PATCH 1/2] xwayland-input: Fix a crasher for a race with the Wayland compositor

If something quickly maps and unmaps a window, then we'll immediately create and destroy the Wayland surface that cooresponds to that window. If our mouse pointer is over the window when the surface is created, we'll receive a enter on the window. Since resource creation and destruction is not

Re: xserver dependency on crypto library because of a hashmap

Nevertheless, SHA-1 is a cryptographic hash function and an extremely poor choice for hash tables. Have we considered using the classic djb2 instead? On Jun 8, 2014 5:37 PM, Rémi Cardona r...@gentoo.org wrote: Le dimanche 08 juin 2014 à 15:46 +0200, Marek Behun a écrit : 300 lines of code only

Re: Alternative approach for a nested-xserver based video driver

And on the other side, you have people like me who simply want to replace all video drivers with -modesetting, and all input drivers with libinput :) On Wed, Jun 4, 2014 at 12:16 PM, Jamey Sharp ja...@minilop.net wrote: On Wed, Jun 04, 2014 at 09:07:22AM -0300, Laércio de Sousa wrote: Hello

Re: [PATCH] configure: Require sufficiently new wayland-client for xwayland ddx

I'd prefer it if we got an updated and working Xwayland like rawhide has, but better error messages are always appreciated. Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net On Mon, Jun 2, 2014 at 1:32 PM, Adam Jackson a...@nwnk.net wrote: On Wed, 2014-05-21 at 09:22 -0400, Adam Jackson

Re: Xorg copyright infrigement

The VESA CVT standard is still free, by the way. You can find download instructions for accessing any VESA public standard here: http://www.vesa.org/wp-content/uploads/2010/12/thankspublic.htm On Mon, Apr 28, 2014 at 5:08 AM, Egbert Eich e...@freedesktop.org wrote: On Sun, Apr 27, 2014 at

Re: Xorg copyright infrigement

On Sun, Apr 27, 2014 at 6:28 AM, Mateusz Jończyk mat.jonc...@o2.pl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, W dniu 27.04.2014 11:33, Luc Verhaegen pisze: Thanks so very much for taking me in CC. Right, I should have CC You. Please excuse me. I am new to this project.

Re: [PATCH] Add a command line argument for disabling indirect GLX.

I'd be surprised if pretty much any GL application works using the indirect GLX extension. It's only specified up to GL 1.4, which was released over 12 years ago. On Thu, Apr 24, 2014 at 9:32 AM, James Cloos cl...@jhcloos.com wrote: Does preventing indirect glx prevent glx over x over tcp?

[PATCH] dixfonts: Turn a missing directory ErrorF into a DebugF

On systems without these directories, we don't need to be complaining loudly. Reviewed-by: Kristian Hoegsberg k...@bitplanet.net --- dix/dixfonts.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dix/dixfonts.c b/dix/dixfonts.c index 83d2539..1c6442c 100644 ---

Re: [PATCH libXfont] Fix buffer read overrun

Always using strlen(s); should be fine. The compiler will optimize it out for a literal string anyway. On Fri, Apr 18, 2014 at 4:39 PM, Keith Packard kei...@keithp.com wrote: Alan Coopersmith alan.coopersm...@oracle.com writes: They work, as long as you only ever pass a literal string to

Re: [BUG] Window resizing broken

Resizing by window borders is a WM operation, is it not? What WM are you using, and does it work on other WMs? On Mon, Apr 7, 2014 at 2:56 AM, Knut Petersen knut_peter...@t-online.dewrote: Hi everybody: Problem: Resizing of windows is broken as it is impossible to grab a window border.

Re: [PATCH 2/7] composite: Add exception mechanism for implicit redirection policy

Does this mean this mean that reparenting an RGB24 visual window into an ARGB32 visual window will only be copy-free on Xwayland and not Xorg? On Tue, Apr 1, 2014 at 2:53 AM, Kristian Høgsberg k...@bitplanet.net wrote: Normally composite will decide to add implicit redirection when a window

Re: [PATCH v2 2/2] xf86LogInit: log to XDG_DATA_HOME when not running as root

It seems to me like they should be in ~/.cache/, which is where non-important files that are mostly transient should go. On Wed, Mar 26, 2014 at 10:15 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 03/26/2014 12:51 PM, Mark Kettenis wrote: From: Hans de Goede hdego...@redhat.com

Re: [PATCH xinit 2/3] startx: Under Linux start X on the current VT

On Tue, Mar 25, 2014 at 10:02 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 03/25/2014 02:50 PM, Julien Cristau wrote: On Tue, Mar 25, 2014 at 12:56:35 +0100, Hans de Goede wrote: When we let X allocate a new VT, systemd-logind will not recognize any processes running on this VT

Re: [PATCH 15/20] glamor: Provide a placeholder for glamor_pushpixels

On Thu, Mar 20, 2014 at 7:23 PM, Eric Anholt e...@anholt.net wrote: Keith Packard kei...@keithp.com writes: This just calls miPushPixels until glamor uses FBOs for bitmaps The only cases that PushPixels() is called that I can find: - miglblt.c We're doing hand-accelerated glyph blits,

Re: [PATCH synaptics] man: setting scroll deltas to 0 doesn't work (#75074)

Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net On Mon, Feb 17, 2014 at 7:17 PM, Peter Hutterer peter.hutte...@who-t.netwrote: 6d47d33 disallows a zero value for horizontal/vertical scroll deltas but the man page wasn't updated. We've added separate toggles to enable/disable scrolling

Re: [PATCH:mkcomposecache] Replace manual calculations of memory allocations with asprintf calls

I didn't know asprintf was standardized. Nice to hear it! Reviewed-by: Jasper St. Pierre jstpie...@mecheye.net On Wed, Feb 19, 2014 at 1:23 AM, Alan Coopersmith alan.coopersm...@oracle.com wrote: Includes fallback asprintf() for pre-Unix08 platforms Signed-off-by: Alan Coopersmith

Re: [PATCH v2 10/14] systemd-logind: Add systemd-logind core

, Jasper St. Pierre wrote: Something I noticed here is that you use GetSessionByPID(). This works right now, but with systemd user sessions, the display server will run outside of a session. We have to decide what to do in this case. AFAIK that won't work, the display server must be inside

Re: [PATCH 01/12] dbus-core: Move to hw/xfree86/common dir

It would mean that we can finally use malloc(); and other reentrant-unsafe functions in that codepath, which would be a really good code cleanup. On Thu, Jan 30, 2014 at 5:14 PM, Peter Hutterer peter.hutte...@who-t.netwrote: On Thu, Jan 30, 2014 at 12:46:12PM -0500, James Cloos wrote: [Still

Re: How do we want to deal with 4k tiled displays?

Is there a reason we can't somehow merge the two CRTCs together into one virtual CRTC? Too difficult to modeset? On Thu, Jan 16, 2014 at 2:11 PM, Aaron Plattner aplatt...@nvidia.comwrote: So, monitor manufacturers are starting to make high-resolution displays that consist of one LCD panel

  1   2   >