From: Michel Dänzer
This will disable the HW cursor while a transform is active on the CRTC.
Signed-off-by: Michel Dänzer
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
b/hw
On 12.12.2015 00:47, Jon Turney wrote:
> On 11/12/2015 10:31, Emil Velikov wrote:
>> On 11 December 2015 at 10:20, Martin Peres wrote:
>>> On 11/12/15 11:30, Michel Dänzer wrote:
>>>> On 11.12.2015 18:17, Martin Peres wrote:
>>>>> On 11/12/15 04:34, M
CmdName() here to keep avoid a
> potential null-pointer dereference? Actually include/client.h tells
> you you shuld ;).
You're right, fixed in v3.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
f it were
local.
v2: (Michel Dänzer)
* Only match "ssh" itself, not other executable names starting with
that prefix.
* Ignore executable path for the match.
v3: (Michel Dänzer)
* Use GetClientCmdName (Mark Kettenis)
* Perform check on Windows as well, but o
RegisterRootWindowProperty().
>
> v2: rebase
>
> Signed-off-by: Leo Liu
> Signed-off-by: Michel Dänzer
[...]
> @@ -1865,7 +1866,9 @@ xf86RegisterRootWindowProperty(int ScrnIndex, Atom
> property, Atom type,
> pNewProp->type = type;
> pNewProp->format =
\
>tmp = __container_of(pos->member.next, pos, member); \
>&pos->member != (head);\
Yes, but the xorg_list_for_each_entry macro needs the same treatment.
With that,
Acked-by: Michel Dänzer
--
Earthling Mich
c/radeon_kms.c
> +++ b/src/radeon_kms.c
> @@ -303,7 +303,7 @@ static void
> radeon_dirty_update(ScreenPtr screen)
> {
> RegionPtr region;
> - PixmapDirtyUpdatePtr ent;
> + PixmapDirtyUpdatePtr ent = NULL;
>
> if (xorg_list_is_empty(&screen->pixmap_dirty_list))
>
On 11.12.2015 18:17, Martin Peres wrote:
> On 11/12/15 04:34, Michel Dänzer wrote:
>> From: Adam Jackson
>>
>> By the time we get to ComputeLocalClient, we've already done
>> NextAvailableClient → ReserveClientIds → DetermineClientCmd (assuming
>> we'
From: Leo Liu
same monitor modes added causing memory leak
when looping `xrandr --prop'.
Signed-off-by: Leo Liu
Signed-off-by: Michel Dänzer
---
More than two years later... Can somebody pick this up?
hw/xfree86/modes/xf86EdidModes.c | 22 ++
1 file change
Hi Leo,
any chance you could rebase this fix onto current xserver master? If
not, I can give it a shot.
On 07.08.2013 16:53, Michel Dänzer wrote:
> From: Leo Liu
>
> leak happens when looping `xrandr --prop', need free for the mallocated data,
> duplication of passed data
On 11.12.2015 14:45, Keith Packard wrote:
> Michel Dänzer writes:
>
>> +if (!client->local)
>> +return BadRequest;
>
> BadRequest is probably not the error code you want here; perhaps
> BadMatch?
This was copied from ProcDRI2Dispatch. I'm fine w
From: Michel Dänzer
Prevents clients forwarded via SSH from hanging while waiting for the
reply from the DRI3Open request.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93261
Signed-off-by: Michel Dänzer
---
v2: Flesh out commit log, drop RFC
dri3/dri3_request.c | 4
1 file
f it were
local.
v2: (Michel Dänzer)
* Only match "ssh" itself, not other executable names starting with
that prefix.
* Ignore executable path for the match.
Signed-off-by: Adam Jackson
Signed-off-by: Michel Dänzer
---
v2.1: Slightly extended code c
f it were
local.
v2: (Michel Dänzer)
* Only match "ssh" itself, not other executable names starting with
that prefix.
* Ignore executable path for the match.
Signed-off-by: Adam Jackson
Signed-off-by: Michel Dänzer
---
os/access.c | 27 ---
1 fi
d
happen e.g. if ssh is launched from some kind of frontend / script.
P.S. xserver patches should now also use the explicit [PATCH xserver]
prefix.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X develop
On 09.12.2015 13:21, Alex Goins wrote:
> On Tue, 8 Dec 2015, Michel Dänzer wrote:
>> On 26.11.2015 11:39, Alex Goins wrote:
>>>
>>> (Start/Stop)FlippingPixmapTracking are merely the double-buffered
>>> equivalents of (Start/Stop)PixmapTracking, allowing the so
On 09.12.2015 14:01, Keith Packard wrote:
>
> Michel Dänzer writes:
>
>> FWIW, the latter is no reason to remove DRI1 support as a whole AFAICT:
>> SIGIO was only used for DRI1 kernel driven context switching,
>
> It looks like the only non-SIGIO path
d from the Linux kernel version
3.12 more than two years ago in commit b0e898ac ("drm: remove FASYNC
support").
So, it's fairly safe to say that removing SIGIO support would have no
practical impact on the rest of the DRI1 code.
--
Earthling Michel Dänzer
rrcrtc.c
> @@ -383,7 +383,6 @@ rrDestroySharedPixmap(RRCrtcPtr crtc, PixmapPtr pPixmap) {
> void
> RRCrtcDetachScanoutPixmap(RRCrtcPtr crtc)
> {
> -ScreenPtr master = crtc->pScreen->current_master;
> rrScrPriv(crtc->pScreen);
>
> pScrPriv->rrCrtcSetScanoutPixm
From: Michel Dänzer
---
Unfortunately, this doesn't help for DRI3 clients hanging waiting for the
reply from the DRI3Open request with display connections forwarded via
SSH (see https://bugs.freedesktop.org/show_bug.cgi?id=93261), because the
SSH proxy client appears local to the X server.
AICT there's no implementation of these hooks in this series. Is it
really necessary (or even worth) adding these hooks instead of just
calling Start/StopPixmapTracking separately for the front and back pixmaps?
--
Earthling Michel Dänzer | http://www.amd.com
Libre
map() in RRCrtcDetachScanoutPixmap().
That would leave the risk of StopPixmapTracking never getting called,
leaving a dangling reference to the destroyed pixmap.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software en
From: Michel Dänzer
This makes sure that the destination pixmap contents will be fully
initialized. Without this, a PRIME output starts out with garbage.
Signed-off-by: Michel Dänzer
---
dix/pixmap.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/dix/pixmap.c b/dix
From: Michel Dänzer
Otherwise, we leave a dangling reference to the destroyed pixmap in the
master screen's pixmap_dirty_list.
Fixes regression from commit cf5d6414 ("randr: Factor out shared pixmap
destruction").
Signed-off-by: Michel Dänzer
---
randr/rrcrtc.c | 11
s in the log file.
xf86-input-evdev works.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://
ink would be to add another
> sink ABI function for the source to use to trigger a flip after a deferred
> present.
I meant that no flip should be submitted either while there's no damage.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enth
vbl.request.sequence = 1;
> +vbl.request.signal = (unsigned long) ppriv_front->flipSeq;
> +
> +if (drmWaitVBlank(drmmode->fd, &vbl) >= 0)
> +return TRUE;
> +}
In the !noflip case (BTW, double negatives are kind of bad), s
mention xf86-video-fbdev.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archiv
t; present_set_tree_pixmap(screen->root, NULL, pixmap);
>
Have you found a less hackish solution in the meantime?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
gt; -
> (*screen->GetScreenPixmap)(screen));
> -present_set_tree_pixmap(window, pixmap);
> -present_set_tree_pixmap(screen->root, pixmap);
> + screen_priv->flip_pixmap
t; int num_notifies;
> Boolqueued; /* on present_exec_queue */
> +Boolrequeue;/* on queue, but target_msc has
> changed */
> Bool flip; /* planning on using flip */
> Bool
flip_serial;
> PixmapPtr flip_pixmap;
> present_fence_ptr flip_idle_fence;
> +Boolflip_sync;
>
> present_screen_info_ptr info;
> } present_screen_priv_rec, *present_screen_priv_ptr;
>
Reviewed-by:
LX: enabled GLX_MESA_copy_sub_buffer
[ 1243.738] (II) AIGLX: Loaded and initialized swrast
[ 1243.738] (II) GLX: Initialized DRISWRAST GL provider for screen 0
The problem seems to be that the DRI2 client driver name is incorrectly
determined as radeon instead of r600, so AIGLX fails to load
dianness issue, but this is all on bog-standard
> little-endian x86 hardware.
>
> Any clues in tracking this down would be appreciated.
Please provide the log files and the output of glxinfo for the bad case
with modesetting and for the good case with radeon (preferably b
needs to be the bottom of the stack (it calls fb directly and
> doesn't wrap). Caught by Michel.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
a entries is
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92894
With that fixed,
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X
it to the screen.
>
> v2: Just use pixmap->usage_hint instead of a new field. Drop the
> changes that started storing gbm_bos in the pixmap priv due to
> lifetime issues.
>
> Signed-off-by: Eric Anholt
> Reviewed-by: Michel Dänzer
This is slightly misl
yer calls glamor_destroy_pixmap, which is hardcoded to call
fbDestroyPixmap.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.o
call. One new test (rendercheck's
> large_blend_src) fails compared to a working i965 on server master,
> but the series doesn't make it worse.
>
> The code can be found on the glamor-gloom branch of my tree.
The series is
Reviewed-by: Michel Dänzer
--
Earthling Mic
is is available in the glamor-delay-shareable branch of my tree.
Patches 1 & 3-9 are
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
bm_bo_destroy(pixmap_priv->gbm);
> +pixmap_priv->gbm = NULL;
> +}
Should this pixmap_priv->gbm block be added in patch 10?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
y: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/x
AR : 0) |
> +#endif
> + GBM_BO_USE_RENDERING | GBM_BO_USE_SCANOUT);
This can check pixmap->usage_hint == CREATE_PIXMAP_USAGE_SHARED, no need
for adding the pixmap_priv->usage_shared field.
With that fixed, this patch is
Reviewed-by: Michel Dänzer
--
Earthling Michel Dän
map, TRUE, valid,
> x_off, y_off))
> +{
> +vblank->flip = TRUE;
> +vblank->sync_flip = TRUE;
> target_msc--;
> +} else if ((screen_priv->info->capabilities &
> PresentCapabilityAsync) &&
> +present_check_flip (t
On 05.11.2015 12:05, Michel Dänzer wrote:
> On 05.11.2015 01:51, davya...@free.fr wrote:
>> On 04/11/2015 11:01, Chris Wilson wrote:
>>> On Wed, Nov 04, 2015 at 10:48:40AM +0100, Axel Davy wrote:
>>>>
>>>> . Why you check for Async flips first (
t msc with the async
> option,
> incrementing target_msc means you wait vblank to present. Ie you enforce
> swap interval == 1, which is not what we want. However not increasing
> target_msc will trigger the copy directly, which is what the user expects.
Makes sense to me.
--
Earthling
ions & PresentOptionAsync)
even if target_msc <= crtc_msc?
> +} else if (target_msc == crtc_msc &&
> +(options & PresentOptionAsync) &&
> + (screen_priv->info->capabilities & PresentCapabilityAsync) &
crtc_msc) || (!pixmap && target_msc >
> crtc_msc)) {
> +if (target_msc > crtc_msc) {
> ret = present_queue_vblank(screen, target_crtc, vblank->event_id,
> target_msc);
> if (ret == Success)
> return Success;
>
Looks
From: Michel Dänzer
Fixes DRI2 client driver name mapping for newer AMD GPUs with the
modesetting driver, allowing the DRI2 extension to initialize.
Signed-off-by: Michel Dänzer
---
hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 28
1 file changed, 28 insertions
On 26.10.2015 20:01, Emil Velikov wrote:
> On 26 October 2015 at 10:55, Daniel Martin wrote:
>> On 26 October 2015 at 10:39, Michel Dänzer wrote:
>>>> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
>>>> index 64e79d4..f0f121e 100644
>>>&g
the user switched to
> another VT.
>
> Signed-off-by: Stephen Chandler Paul
> Reviewed-by: Michel Dänzer
> ---
> Changes
> * We no longer assign the return value of drmModeSetCrtc to ret, instead we
> just check it in the conditional
>
output_count, &kmode) != 0) {
xf86DrvMsg(crtc->scrn->scrnIndex, X_ERROR,
"failed to set mode: %s",
strerror(errno));
ret = FALSE
amor: make current in
prepare paths")
0a458a908ec071a4da5d22c760581e0c5ec885ce ("glamor: Make our EGL context
current before calling into GL in glamor_init")
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 02.10.2015 23:46, Alex Deucher wrote:
> On Fri, Oct 2, 2015 at 5:11 AM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> When using glamor acceleration, the pixmap's header has to have a height
>> that matches exactly what the actual height is minus the GP
From: Michel Dänzer
When using glamor acceleration, the pixmap's header has to have a height
that matches exactly what the actual height is minus the GPU memory
alignment. Otherwise CRTCs scanning out from the main scanout buffer
(e.g. every CRTC that isn't rotated or transformed i
On 29.09.2015 11:55, Fredrik Höglund wrote:
> On Friday 11 September 2015, Michel Dänzer wrote:
>> On 11.09.2015 06:33, Fredrik Höglund wrote:
>>> Otherwise we stash an uninitalized value, and later use it to compute
>>> the msc_offset for the window. Also initia
need_swap_rb = IS_LITTLE_ENDIAN ? 1 : 0;;
> +need_swap_rb = IS_LITTLE_ENDIAN ? 1 : 0;
> break;
>
> case PICT_x1b5g5r5:
>
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre softwa
On 25.09.2015 22:04, Emil Velikov wrote:
> Otherwise we'll fail and/or crash as no context is bound.
>
> Fixes: 64e6124f27e(glamor: move GL_OES_EGL_image check next to
> EGL_EXT_image_dma_buf_import)
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92105
> Cc: Mi
+ErrorF("GL_OES_EGL_image not available\n");
> +goto fail;
> +}
> +
> glamor_priv->has_rw_pbo = FALSE;
> if (glamor_priv->gl_flavor == GLAMOR_GL_DESKTOP)
> glamor_priv->has_rw_pbo = TRUE;
>
Reviewed-by: Michel Dän
t_msc
doesn't match window_priv->crtc, presumably present_get_ust_msc() will
fail there as well, so window_priv->msc (the last recorded valid MSC
value for the window) will be added to window_priv->msc_offset. I
suspect that's not right and might still cause similar trouble down t
_ERROR,
> + "[drm] Failed to load kernel module for %s: %s\n",
> + busid, strerror(errno));
> +free(busid);
> +return -1;
> +}
> +#endif
> +
> fd = drmOpen(NULL, busid);
> if (fd == -1)
> xf86DrvM
From: Michel Dänzer
Without this, the context of another screen may be current, or no context
at all if glamor_egl_init failed for another screen.
Signed-off-by: Michel Dänzer
---
glamor/glamor.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a
On 15.07.2015 17:06, Michel Dänzer wrote:
> On 15.07.2015 16:56, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> Lots of the accel paths only make current once they start
>> doing someting, so a lot of them call the bail paths without
>> make current, which means o
>
> Add a prepare pixmap in the prepare fallback path.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90667
> Signed-off-by: Dave Airlie
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
From: Michel Dänzer
Fixes slow text display in xdvi.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91260
Signed-off-by: Michel Dänzer
---
glamor/glamor_image.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/glamor/glamor_image.c b/glamor/glamor_image.c
index
", but the Render code had a lot of bugs
> obscuring that fact.
Patches 1, 3-5, 8, 10-12 are
Reviewed-by: Michel Dänzer
Patch 2: Should the shortlog say "choosing format" instead of "choosing
color"? Either way,
Reviewed-by: Michel Dänzer
Patch 9: Maybe add an
LAMOR_FBO_NORMAL)
I guess these macros could be removed now, but that's for later.
The series is
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
From: Michel Dänzer
Instead of one glTexSubImage2D call for each glyph.
This significantly reduces the amount of time it takes for xterm to start
up on a fresh X server with the radeonsi driver.
v2: Use GLYPHWIDTHBYTESPADDED instead of hardcoding 4 bytes glyph
alignment (Keith Packard
From: Michel Dänzer
Instead of one glTexSubImage2D call for each glyph.
This significantly reduces the amount of time it takes for xterm to start
up on a fresh X server with the radeonsi driver.
Signed-off-by: Michel Dänzer
---
glamor/glamor_font.c | 37
xinit: After an assertion failure, they're
left with a black screen and no obvious way to restore sanity locally.
Anyway, that probably needs to be dealt with elsewhere, so
Acked-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.a
because I didn't have bitmap fonts enabled in the fontconfig
configuration there.
Reviewed-and-Tested-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 02.07.2015 09:43, Eric Anholt wrote:
> This should help people debugging when glamor does something stupid on
> their driver.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre softwar
On 01.07.2015 07:09, Eric Anholt wrote:
> Michel Dänzer writes:
>
>> On 30.06.2015 13:02, Keith Packard wrote:
>>>
>>> commit 9c679d06055cc62aa9209318705e87dc33fba4c8
>>> Author: Eric Anholt
>>> Date: Sun May 31 16:07:01 2015 -0700
>>>
ome of it only "after a
while").
Looking at the glamor code, it doesn't seem to be as simple as setting
GLAMOR_CREATE_FBO_NO_FBO and not getting an FBO. E.g.
glamor_glyphs_flush() uses glamor_pixmap_fbo_at() to get the atlas
texture ide
ree86/drivers/modesetting/driver.c
> +++ b/hw/xfree86/drivers/modesetting/driver.c
> @@ -820,7 +820,6 @@ PreInit(ScrnInfoPtr pScrn, int flags)
> try_enable_glamor(pScrn);
>
> if (ms->drmmode.glamor) {
> -xf86LoadSubModule(pScrn, "dri2");
> } e
s less likely to be an issue in
practice)
I solved that in the radeon driver by making the drm_queue abstraction
itself track IDs of events (though I just realized I can take that a bit
further still).
--
Earthling Michel Dänzer | http://www.amd.com
Libre sof
On 24.06.2015 20:38, Emil Velikov wrote:
> On 23 June 2015 at 02:46, Michel Dänzer wrote:
>> On 23.06.2015 04:28, Emil Velikov wrote:
>>> On 22 June 2015 at 07:56, Michel Dänzer wrote:
>>>> On 20.06.2015 07:32, Dave Airlie wrote:
>>>>>>
>>&
void reaching the maximum number of clients prematurely.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=91072
>
> Reported-and-tested-by: Olivier Fourdan
> Signed-off-by: Chris Wilson
With the above fixed,
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer
On 23.06.2015 04:28, Emil Velikov wrote:
> On 22 June 2015 at 07:56, Michel Dänzer wrote:
>> On 20.06.2015 07:32, Dave Airlie wrote:
>>>>
>>>>> at which point you'd want to continue
>>>>> the versioning from the mesa point to avoid epochs.
x27;t
> escape the fact that other gbm implementations are currently doing it
> wrong if they want to be API compatible.
I think one fundamental issue is that we're trying to determine the GBM
runtime ABI from compile time constants. One possible solution m
ng a pixmap if it can support HW cursor */
> +xorg_list_for_each_entry(ent, &pScreen->pixmap_dirty_list, ent) {
> +pSlave = ent->slave_dst->drawable.pScreen;
> +xf86ScreenMoveCursor(pSlave, x, y);
> +}
> +}
> +
> +void
> xf86RecolorCursor(Screen
EAR" = xyes; then
> + AC_DEFINE(GLAMOR_HAS_GBM_LINEAR, 1,
> + [Build glamor/gbm has linear support])
> + fi
It would be better to use AC_CHECK_DECL for this, as is done in
xf86-video-amdgpu. That way it does the right thing ev
> wants to assign GPU devices can specify it in the xorg.conf
> for this use case.
>
> Signed-off-by: Dave Airlie
Tested-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
t; is to start with a black root window, and to suppress display of the cursor
> until the first time an application calls XDefineCursor(). For kdrive
> servers, this implies -zap.
>
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
On 28.05.2015 18:30, Chris Wilson wrote:
> On Thu, May 28, 2015 at 06:27:34PM +0900, Michel Dänzer wrote:
>> On 28.05.2015 18:07, Chris Wilson wrote:
>>> On Thu, May 28, 2015 at 05:56:15PM +0900, Michel Dänzer wrote:
>>>> On 28.05.2015 17:38, Chris Wilson wrote:
>&
On 28.05.2015 18:07, Chris Wilson wrote:
> On Thu, May 28, 2015 at 05:56:15PM +0900, Michel Dänzer wrote:
>> On 28.05.2015 17:38, Chris Wilson wrote:
>>> On Thu, May 28, 2015 at 04:59:14PM +0900, Michel Dänzer wrote:
>>>> The patch below is an alternative fix for
On 28.05.2015 17:38, Chris Wilson wrote:
> On Thu, May 28, 2015 at 04:59:14PM +0900, Michel Dänzer wrote:
>> On 27.05.2015 15:51, Chris Wilson wrote:
>>> On Tue, May 26, 2015 at 02:30:32PM -0700, Keith Packard wrote:
>>>> Michel Dänzer writes:
>>>>
>&
On 27.05.2015 15:51, Chris Wilson wrote:
> On Tue, May 26, 2015 at 02:30:32PM -0700, Keith Packard wrote:
>> Michel Dänzer writes:
>>
>>> The old code also called present_get_crtc() unless pixmap == NULL, so
>>> the problem couldn't affect flips but only
rno != EBUSY || !ms_flush_drm_events(screen))
> +/* If we hit EBUSY, then try to flush events. If we can't, then
> + * this is an error.
> + */
> +if (errno != EBUSY || ms_flush_drm_events(screen) <= 0)
> return BadAlloc;
>
On 27.05.2015 07:12, Keith Packard wrote:
> Michel Dänzer writes:
>
>> Keith, this is also an important fix:
>>
>> On 06.02.2015 17:25, Chris Wilson wrote:
>>> As we unflip after the flip Window no longer passes the pixel ownership
>>> test for the fu
On 27.05.2015 06:30, Keith Packard wrote:
> Michel Dänzer writes:
>
>> The problem I was hitting was that this code was running for an MSC wait
>> when the CRTC referenced by window_priv->crtc was already disabled for
>> DPMS off. This caused hangs at the GNOME lo
ale screen contents when
unflipping, e.g. when quitting a fullscreen app or switching from
fullscreen to windowed mode.
Reviewed-and-Tested-by: Michel Dänzer
> ---
> present/present.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/present/presen
angs at the GNOME lock screen. This patch seems
to fix that problem.
So, I vote for applying this patch (possibly with a better commit log)
to master ASAP and backporting it to stable branches.
Reviewed-and-Tested-by: Michel Dänzer
> ---
> present/present.c | 11 ++-
> 1 file change
nholt
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90442
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-d
ur.
The discussion about this on IRC sounded to me like we don't want to do
this for both signals, because at least one of them should interrupt
select(). My guess would be that SIGIO should interrupt select() and
thus shouldn't use SA_RESTART.
--
Earthling Michel Dänzer
or->bits->yhot);
> +if (!ret)
> +return;
> if (ret == -EINVAL)
> use_set_cursor2 = FALSE;
> -else
> -return;
> }
>
> ret = drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id,
> handle,
&
return FALSE;
> +
> +/* Make sure there's a bo we can get to */
> +/* XXX: actually do this. also...is it sufficient?
> + * if (!glamor_get_pixmap_private(pixmap))
> + * return FALSE;
> + */
> +
> +re
On 22.04.2015 00:51, Aaron Plattner wrote:
> Is there any chance you could use the new OutputClass match rules in
> /usr/share/X11/xorg.conf.d rather than adding to this list?
Yes, that seems to work nicely. :) Thanks for the suggestion!
This patch is retracted.
--
Earthling Michel
From: Michel Dänzer
Its Probe hook bails cleanly when it can't initialize, in which case the
ati driver will be tried next.
Signed-off-by: Michel Dänzer
---
hw/xfree86/common/xf86pciBus.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/xfree86/common/xf86pciBus.c
UMBER;
>
Brent Collins posted essentially the same fix about two weeks ago in
551c330c.9010...@trustedcs.com:
http://lists.x.org/archives/xorg-devel/2015-April/046068.html
Can you guys work out how to get this in?
--
Earthling Michel Dänzer | http://www.amd.com
Libre
601 - 700 of 1388 matches
Mail list logo
