"Jasper St. Pierre" writes:
> Writing error-safe code that uses Xlib is too obnoxious, and using XCB
> is tedious and not performant, as we can't catch events on a giant
> stream -- we have to check every operation manually.
You get errors returned in the event stream; is there something fancier
On Fri, 13 Nov 2015 17:57:22 +0100
Olivier Fourdan wrote:
> When unplugging an output, it's still listed in xrandr and the size
> of the root window still includes the removed output.
>
> The XRandR output should be destroyed when its Wayland counterpart is
> destroyed and the screen dimensions
Mark Kettenis writes:
> This function is used by the modesetting driver to implement DRI2 and
> shouldn't fail on systems that don't support DRI3.
If glamor_egl_dri3_fd_name_from_tex works on systems not using DRI3,
then it better have its name changed to match reality.
--
-keith
signature.a
Dave Airlie writes:
> +pEnt = xf86GetEntityInfo(entity_num);
Can this fail?
--
-keith
signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://l
Mark Kettenis writes:
> Currently glamor hits an assertion on systems that don't have
> xshmfence. This happens when the glamor code calls
> miSyncGetScreenFuncs() because the miSyncScreenPrivateKey has not been
> set up. For systems with xshmfence, this happens when
> miSyncShmScreenInit() get
On 16 November 2015 at 02:57, Mark Kettenis wrote:
> Commit 19e1dc8f6ea6d7ff5ba4a5caa0e2f40a47879408 broke the modesetting
> driver quite badly on systems without XSERVER_PLATFORM_BUS. The
> problem is that the "entity private" only gets set up when
> ms_platform_probe() gets called, but is used
Pretty much just ported what radeon does here.
Reported-by: Mark Kettenis
Signed-off-by: Dave Airlie
---
hw/xfree86/drivers/modesetting/driver.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/hw/xfree86/drivers/modesetting/driver.c
b/hw/xfree86/drivers/modesetting/
This isn't used anywhere, so no point storing it until we need it.
Signed-off-by: Dave Airlie
---
hw/xfree86/drivers/modesetting/driver.c | 8 +---
hw/xfree86/drivers/modesetting/driver.h | 3 ---
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/hw/xfree86/drivers/modesetting/d
> Date: Sun, 15 Nov 2015 09:53:57 -0800
> From: "Jasper St. Pierre"
>
> Should we just unconditionally enable xshmfence? Are there any OSes
> we care about that can't implement a fence primitive?
There currently is no implementation on OpenBSD, and that's the
platform I care about ;).
The futex
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
Currently glamor hits an assertion on systems that don't have
xshmfence. This happens when the glamor code calls
miSyncGetScreenFuncs() because the miSyncScreenPrivateKey has not been
set up. For systems with xshmfence, this happens when
miSyncShmScreenInit() gets called, but that code is wrapped
Commit 19e1dc8f6ea6d7ff5ba4a5caa0e2f40a47879408 broke the modesetting
driver quite badly on systems without XSERVER_PLATFORM_BUS. The
problem is that the "entity private" only gets set up when
ms_platform_probe() gets called, but is used unconditionally in the
driver. So on systems where ms_platf
This function is used by the modesetting driver to implement DRI2 and
shouldn't fail on systems that don't support DRI3.
Signed-off-by: Mark Kettenis
---
glamor/glamor.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index d4a0236..110bdb8 100644
--- a/gla
13 matches
Mail list logo
