Currently if modesetting ever fails to set a hardware cursor it will switch
to using a software cursor and never go back. Change this to try a hardware
cursor first every time a new one is set. This is needed because hardware
may be able to handle some cursors in harware and others not, or
https://bugs.freedesktop.org/show_bug.cgi?id=94414
Michel Dänzer changed:
What|Removed |Added
QA Contact|xorg-t...@lists.x.org
https://bugs.freedesktop.org/show_bug.cgi?id=94414
Michel Dänzer changed:
What|Removed |Added
Attachment #122194|text/plain |image/png
https://bugs.freedesktop.org/show_bug.cgi?id=32789
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=90789
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
On 10.03.2016 10:51, Dave Airlie wrote:
> From: Dave Airlie
>
> For some putimages we know we won't ever care about the data we readback,
> we are going to trash it with the putimage contents. So implement
> GLAMOR_ACCESS_WO mode.
>
> This will avoid doing the readbacks. Use
https://bugs.freedesktop.org/show_bug.cgi?id=94414
--- Comment #8 from Jean-Philippe Gariépy ---
Note that I'm seeing this "r300: CS space validation failed." message.
This seems to come from Mesa:
mesa/src/gallium/drivers/r300/r300_render.c
Not sure what is the exact cause
https://bugs.freedesktop.org/show_bug.cgi?id=94414
Jean-Philippe Gariépy changed:
What|Removed |Added
Resolution|INVALID |---
https://bugs.freedesktop.org/show_bug.cgi?id=94414
--- Comment #5 from Jean-Philippe Gariépy ---
Created attachment 122192
--> https://bugs.freedesktop.org/attachment.cgi?id=122192=edit
journalctl (filtered with gdm-x-session and gnome-shell.desktop)
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=94414
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |INVALID
https://bugs.freedesktop.org/show_bug.cgi?id=94414
--- Comment #3 from Jean-Philippe Gariépy ---
Created attachment 122189
--> https://bugs.freedesktop.org/attachment.cgi?id=122189=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the
From: Dave Airlie
For some putimages we know we won't ever care about the data we readback,
we are going to trash it with the putimage contents. So implement
GLAMOR_ACCESS_WO mode.
This will avoid doing the readbacks. Use it for putimages that are copy
with a solid
Michel Dänzer writes:
> Sounds good to me.
>
> One thing that might be nice to do as part of your patch would be moving
> the xf86_config->cursor = NULL assignment from xf86_cursors_init to
> xf86_hide_cursors. That way xf86_config->cursor would always be NULL
> while the
On Wed, 2016-03-09 at 10:59 -0500, Olivier Fourdan wrote:
> Reviewed-by: Olivier Fourdan
remote: I: patch #76365 updated using rev
723881f31d65353e80660e6d8cd9785e6ec1b430.
remote: I: 1 patch(es) updated to state Accepted.
To
On Wed, 2016-03-09 at 16:45 +0100, Olivier Fourdan wrote:
> Signed-off-by: Olivier Fourdan
Merged this and the xwayland xv support:
remote: E: failed to find patch for rev
da7724d3d277c6c8a814881785b716896802629a.
remote: I: patch #76376 updated using rev
On Wed, 2016-03-09 at 16:31 +, Jon Turney wrote:
> The following changes since commit 24042b4e367803dd64f3fcdc1bef7b2bf36c4145:
>
> modesetting: Allow CRTC transforms to actually take effect (2016-03-09
> 16:46:13 +0900)
>
> are available in the git repository at:
>
>
On Wed, Mar 9, 2016 at 4:46 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Sync-to-vblank works fine with rotation. We're still checking for
> rotation in radeon_present_check_flip.
>
> Returning NULL from here resulted in the xserver present code
The following changes since commit 24042b4e367803dd64f3fcdc1bef7b2bf36c4145:
modesetting: Allow CRTC transforms to actually take effect (2016-03-09
16:46:13 +0900)
are available in the git repository at:
git://people.freedesktop.org/~jturney/xserver
for you to fetch changes up to
- Original Message -
> Looks good to me.
>
> Funny that we have:
> #define XvNumReasons (XvLastReason + 1)
> and a few lines below it:
> #define XvAnyReasonMask ((1L< Anyway,
>
> Reviewed-by: Olivier
- Original Message -
> We typically store these in ints in server, leading to warnings like:
>
> xwayland-glamor-xv.c: In function ‘xwl_glamor_xv_add_adaptors’:
> xwayland-glamor-xv.c:339:16: warning: large integer implicitly truncated
> to unsigned type [-Woverflow]
> pa->type =
Signed-off-by: Olivier Fourdan
---
glamor/Makefile.am | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/glamor/Makefile.am b/glamor/Makefile.am
index c488029..c631c53 100644
--- a/glamor/Makefile.am
+++ b/glamor/Makefile.am
@@ -46,10 +46,14 @@
This adds an Xv adaptor using glamor.
Signed-off-by: Olivier Fourdan
---
v2: Plug leak of Xv adaptor and glamor private ports array on closure
v3: Get the adaptor size from the GL_MAX_TEXTURE_SIZE
v4: Fix double comma and unsigned int warning, fix build with --disable-xv
On Wed, 2016-03-09 at 14:35 +0100, Daniel Albers wrote:
> Signed-off-by: Daniel Albers
Merged, thanks:
remote: I: patch #76361 updated using rev
e1011b9e2f6c82255959cf3cc1d8cda402ded0a9.
remote: I: 1 patch(es) updated to state Accepted.
To
On Tue, 2016-03-08 at 10:15 -0500, Olivier Fourdan wrote:
> Hi Adam,
>
> I had posted a revisited version using GL_MAX_TEXTURE_SIZE to
> determine the encoder size as per your review last week, is there
> anything else that needs rework?
This adds a warning, but I don't think that's your fault:
We typically store these in ints in server, leading to warnings like:
xwayland-glamor-xv.c: In function ‘xwl_glamor_xv_add_adaptors’:
xwayland-glamor-xv.c:339:16: warning: large integer implicitly truncated
to unsigned type [-Woverflow]
pa->type = XvWindowMask | XvInputMask | XvImageMask;;
On Wed, 2016-03-09 at 16:51 +0900, Michel Dänzer wrote:
> Hi Keith / Adam,
>
>
> the following changes since commit a3e681eafa5355b8bb3b099d47983f14f0d5e197:
>
> glamor: Source pictures are always depth 32 (2016-03-08 15:17:19 -0500)
>
> are available in the git repository at:
>
>
Signed-off-by: Daniel Albers
---
nls/en_US.UTF-8/Compose.pre | 2 ++
1 file changed, 2 insertions(+)
diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre
index 2041757..d88fe36 100644
--- a/nls/en_US.UTF-8/Compose.pre
+++ b/nls/en_US.UTF-8/Compose.pre
@@ -278,6
On Tue, 2016-03-08 at 16:10 -0800, russell.poffenber...@xcerra.com wrote:
> So could there be a bug, or a newer (read fixed) int10 driver in the
> Centos 7 version that can be ported to Centos 6.7? Where can I find
> the package or code for this driver that I may be able to compile for
> Centos
On Tue, 2016-03-08 at 23:56 +, adlo wrote:
> I am writing a window switcher application using GTK that shows live
> previews of windows.
>
> Should I call XDamageSubtract () before or after I update the image
> widget in response to a damage event?
Before, but in another sense, neither. X
Hi,
On 9 March 2016 at 04:27, Jonas Ådahl wrote:
> By default the X server will try CLOCK_MONOTONIC_COARSE before
> CLOCK_MONOTONIC. This causes various issues for Wayland display
> servers who may get their internal timestamps from the CLOCK_MONOTONIC,
> since it may very well
- Original Message -
> - Original Message -
> > Read and dispatch pending Wayland events to make sure we do nto miss a
> > possible reply from the compositor prior to discard a key repeat.
> >
> > Signed-off-by: Olivier Fourdan
> > ---
> >
To be able to reuse some code.
Signed-off-by: Olivier Fourdan
---
v2: call prepre_read() before read() so we don't end up in a deadlock
hw/xwayland/xwayland.c | 44
hw/xwayland/xwayland.h | 2 ++
2 files changed, 34
From: Michel Dänzer
Sync-to-vblank works fine with rotation. We're still checking for
rotation in radeon_present_check_flip.
Returning NULL from here resulted in the xserver present code falling
back to the fake CRTC running at 1 fps.
Signed-off-by: Michel Dänzer
From: Michel Dänzer
Without this, drmmode_set_mode_major may just re-set the FB for the
last flipped BO, in which case the display will probably freeze.
Reproduction recipe: Enable rotation while a fullscreen client is
flipping.
Signed-off-by: Michel Dänzer
- Original Message -
> Read and dispatch pending Wayland events to make sure we do nto miss a
> possible reply from the compositor prior to discard a key repeat.
>
> Signed-off-by: Olivier Fourdan
> ---
> hw/xwayland/xwayland-input.c | 3 +++
> 1 file changed, 3
Read and dispatch pending Wayland events to make sure we do nto miss a
possible reply from the compositor prior to discard a key repeat.
Signed-off-by: Olivier Fourdan
---
hw/xwayland/xwayland-input.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
To be able to reuse some code.
Signed-off-by: Olivier Fourdan
---
hw/xwayland/xwayland.c | 44
hw/xwayland/xwayland.h | 2 ++
2 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/hw/xwayland/xwayland.c
Key repeat is handled by the X server, but input events need to be
processed and forwarded by the Wayland compositor first.
Make sure the Wayland compositor is actually processing events, to
avoid repeating keys in Xwayland while the Wayland compositor cannot
deal with input events for whatever
The xserver generates the key repeat by itself.
But when used with another server processing inputs first (e.g. a
Wayland compositor), the other server may be busy dealing with some
other things and not queue up key release events in time.
Add a vfunc in XkbSrvInfo to possibly add a check before
39 matches
Mail list logo