Re: [PATCH] cache glyphs in the destination format requested to make sure the hardware can use the cached glyphs

[Michel Dänzer]

On 09/01/17 07:36 AM, Michael Lorenz wrote:
> From: Michael Lorenz 
> 
> Signed-off-by: Michael Lorenz 
> ---
>  exa/exa_glyphs.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/exa/exa_glyphs.c b/exa/exa_glyphs.c
> index 192a643cc..7386d05e9 100644
> --- a/exa/exa_glyphs.c
> +++ b/exa/exa_glyphs.c
> @@ -544,7 +544,6 @@ exaBufferGlyph(ScreenPtr pScreen,
> INT16 ySrc, INT16 xMask, INT16 yMask, INT16 xDst, INT16 yDst)
>  {
>  ExaScreenPriv(pScreen);
> -unsigned int format = (GetGlyphPicture(pGlyph, pScreen))->format;
>  int width = pGlyph->info.width;
>  int height = pGlyph->info.height;
>  ExaCompositeRectPtr rect;
> @@ -554,13 +553,10 @@ exaBufferGlyph(ScreenPtr pScreen,
>  if (buffer->count == GLYPH_BUFFER_SIZE)
>  return ExaGlyphNeedFlush;
>  
> -if (PICT_FORMAT_BPP(format) == 1)
> -format = PICT_a8;
> -
>  for (i = 0; i < EXA_NUM_GLYPH_CACHES; i++) {
>  ExaGlyphCachePtr cache = >glyphCaches[i];
>  
> -if (format == cache->format &&
> +if (pDst->format == cache->format &&
>  width <= cache->glyphWidth && height <= cache->glyphHeight) {
>  ExaGlyphCacheResult result = exaGlyphCacheBufferGlyph(pScreen,
>>
> 

Unfortunately, testing reveals that this doesn't work correctly in
general when exaGlyphs is called with maskFormat == NULL, I suspect
because pDst->format may not have any alpha bits here in that case. This
results e.g. in some missing text in xfce4-terminal for me.


-- 
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/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver] AttendClient of grab-pervious client should queue to saved_ready_clients

[Keith Packard]

A client which is attended while a grab is blocking execution of its
requests needs to be placed in the saved_ready_clients list so that it
will get scheduled once the grab terminates. Otherwise, if the client
never sends another request, there is no way for it to be placed in
the ready_clients list.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99333
Signed-off-by: Keith Packard 
---
 dix/dispatch.c  | 7 +++
 include/dixstruct.h | 3 +++
 os/connection.c | 4 
 3 files changed, 14 insertions(+)

diff --git a/dix/dispatch.c b/dix/dispatch.c
index 3d0fe26fd..ab69d34b9 100644
--- a/dix/dispatch.c
+++ b/dix/dispatch.c
@@ -266,6 +266,13 @@ mark_client_ready(ClientPtr client)
 xorg_list_append(>ready, _clients);
 }
 
+/* Client has requests queued or data on the network, but awaits a server grab 
release */
+void mark_client_saved_ready(ClientPtr client)
+{
+if (xorg_list_is_empty(>ready))
+xorg_list_append(>ready, _ready_clients);
+}
+
 /* Client has no requests queued and no data on network */
 void
 mark_client_not_ready(ClientPtr client)
diff --git a/include/dixstruct.h b/include/dixstruct.h
index d71b0ac05..fd9195972 100644
--- a/include/dixstruct.h
+++ b/include/dixstruct.h
@@ -143,6 +143,9 @@ extern void SmartScheduleStopTimer(void);
 /* Client has requests queued or data on the network */
 void mark_client_ready(ClientPtr client);
 
+/* Client has requests queued or data on the network, but awaits a server grab 
release */
+void mark_client_saved_ready(ClientPtr client);
+
 /* Client has no requests queued and no data on network */
 void mark_client_not_ready(ClientPtr client);
 
diff --git a/os/connection.c b/os/connection.c
index a901ebf3c..a2629c8a2 100644
--- a/os/connection.c
+++ b/os/connection.c
@@ -1067,6 +1067,10 @@ AttendClient(ClientPtr client)
 set_poll_client(client);
 if (listen_to_client(client))
 mark_client_ready(client);
+else if (!(oc->flags & OS_COMM_IGNORED)) {
+/* grab active, mark ready when grab goes away */
+mark_client_saved_ready(client);
+}
 }
 
 /* make client impervious to grabs; assume only executing client calls this */
-- 
2.11.0

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH v2 xserver 00/11] modesetting: MS_ALL_IN_ONE

[Alex Deucher]

On Mon, Jan 9, 2017 at 3:27 AM, Hans de Goede  wrote:
> Hi,
>
> On 09-01-17 02:52, Yu, Qiang wrote:
>>
>>
>> Hi Hans,
>>
>> I forgot there is another difference, PRIME solution has to copy screen
>> once before display
>> to iGPU while MS_ALL_IN_ONE don't have to and can display what full screen
>> app draws
>> directly by page flip (for DRI2) which may be important for embedded
>> platforms with week
>> GPU and limited memory bandwidths.
>
>
> Hmm, I guess you're talking imx6 + etnaviv now right, because with a
> discrete GPU
> + iGPU displaying the rendered frame, we are always going to need one copy
> from
> discrete-GPU RAM to system RAM. But I agree that getting rid of the extra
> copy for
> imx6 would be really good, I even dare to call it a must-have feature.

Qiang can correct me if I'm wrong, but I think there are some cases
where it makes more sense for the dGPU to directly access system
memory rather than use vram and copy.

Alex

>
>> Benefit from common interface of drm/gbm/egl, may be modesetting can play
>> a bigger role
>> of span multi drm devices to give more optimization like this and:
>> 1. multi render node, a single protocol screen to accept request and
>> dispatch to each render
>> node for render
>> 2. multi display node associate with the render node (some display node
>> has the same drm
>> device with render node), so no need to handle bo tile-linear copy and
>> each render node can
>> handle request of its related display node.
>
>
> Ack I agree that we would need to do better here, but I don't believe this
> should be some
> special mode activated by some special means, e.g. in the imx6 + etnaviv
> case the modesetting
> driver should simply recognize that they are sharing RAM and use
> page-flipping (passing buffer
> ownership between the 2) rather then copying, without the user needing to do
> anything
> special.
>
> Regards,
>
> Hans
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [tigervnc-devel] PATCH: Add xorg-xserver 1.19 support to tigervnc

[Hans de Goede]

Hi,

On 09-01-17 18:12, Alan Coopersmith wrote:

On 01/ 9/17 07:57 AM, Hans de Goede wrote:

 close(2);
+/* Avoid xserver >= 1.19's epoll-fd becoming fd 2 / stderr only to be
+   replaced by /dev/null by OsInit() because the pollfd is not
+   writable, breaking ospoll_wait(). */
+open("/dev/null", O_WRONLY);


Hopefully no other threads in the X server are opening files, but if any ever
do, it would be more reliable to do:

nullfd = open("/dev/null", O_WRONLY);
dup2(nullfd, 2);
close(nullfd);

and let dup2 atomically close the old stderr and clone nullfd to it.


Yes I agree that would be better, Pierre, can you take care
of merging Alan's improved version ?

Regards,

Hans
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [tigervnc-devel] PATCH: Add xorg-xserver 1.19 support to tigervnc

[Keith Packard]

Alan Coopersmith  writes:

> On 01/ 9/17 07:57 AM, Hans de Goede wrote:
>>  close(2);
>> +/* Avoid xserver >= 1.19's epoll-fd becoming fd 2 / stderr only to be
>> +   replaced by /dev/null by OsInit() because the pollfd is not
>> +   writable, breaking ospoll_wait(). */
>> +open("/dev/null", O_WRONLY);

I'd suggest stripping out the OsInit code which messes with FDs now that
we leave stdin/stdout/stderr alone in the normal case. We should have
done this when the code messing with those FDs was removed.

> Hopefully no other threads in the X server are opening files, but if any ever
> do, it would be more reliable to do:
>
>   nullfd = open("/dev/null", O_WRONLY);
>   dup2(nullfd, 2);
>   close(nullfd);
>
> and let dup2 atomically close the old stderr and clone nullfd to it.

Yeah, this looks like a more reliable fix.

-- 
-keith


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [tigervnc-devel] PATCH: Add xorg-xserver 1.19 support to tigervnc

[Alan Coopersmith]

On 01/ 9/17 07:57 AM, Hans de Goede wrote:

close(2);
+   /* Avoid xserver >= 1.19's epoll-fd becoming fd 2 / stderr only to be
+  replaced by /dev/null by OsInit() because the pollfd is not
+  writable, breaking ospoll_wait(). */
+   open("/dev/null", O_WRONLY);


Hopefully no other threads in the X server are opening files, but if any ever
do, it would be more reliable to do:

nullfd = open("/dev/null", O_WRONLY);
dup2(nullfd, 2);
close(nullfd);

and let dup2 atomically close the old stderr and clone nullfd to it.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [tigervnc-devel] PATCH: Add xorg-xserver 1.19 support to tigervnc

[Hans de Goede]

Hi,

On 09-01-17 10:00, Pierre Ossman wrote:

On 05/01/17 17:44, ipilc...@redhat.com wrote:

On Wednesday, October 5, 2016 at 4:13:48 AM UTC-5, Pierre Ossman wrote:

Alright. I'll have a look at doing the finishing touches. Thanks for the
patch. :)


FYI, there seems to be an issue with either the patch or v1.19 itself.

  https://bugzilla.redhat.com/show_bug.cgi?id=1408724



Urgh. I have no 1.19 system yet, so hopefully someone else can have a look.


Attached is a patch fixing this :)

Regards,

Hans
>From 372ff9d6754cd1b375836e5d4559061fb7be3496 Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Mon, 9 Jan 2017 16:03:30 +0100
Subject: [PATCH] Fix -inetd not working with xserver >= 1.19

xserver 1.19's OsInit will create a pollfd, followed by checking if fd 2 /
stderr is writable and if it is not, replacing fd 2 with /dev/null.

Since we close stderr in inetd mode to avoid xserver messages being send
to the client as vnc data, the pollfd becomes fd 2, only to be replaced
by /dev/null since a pollfd is not writable.

This commit fixes this by opening /dev/null directly after the close(2),
avoiding that the pollfd becomes fd 2.

Signed-off-by: Hans de Goede 
---
 unix/xserver/hw/vnc/xvnc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/unix/xserver/hw/vnc/xvnc.c b/unix/xserver/hw/vnc/xvnc.c
index 2f3cd4a..a747654 100644
--- a/unix/xserver/hw/vnc/xvnc.c
+++ b/unix/xserver/hw/vnc/xvnc.c
@@ -575,6 +575,10 @@ ddxProcessArgument(int argc, char *argv[], int i)
 	dup2(0,3);
 	vncInetdSock = 3;
 	close(2);
+	/* Avoid xserver >= 1.19's epoll-fd becoming fd 2 / stderr only to be
+	   replaced by /dev/null by OsInit() because the pollfd is not
+	   writable, breaking ospoll_wait(). */
+	open("/dev/null", O_WRONLY);
 	
 	if (!displaySpecified) {
 	int port = vncGetSocketPort(vncInetdSock);
-- 
2.9.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [tigervnc-devel] PATCH: Add xorg-xserver 1.19 support to tigervnc

[Hans de Goede]

Hi,

On 09-01-17 10:00, Pierre Ossman wrote:

On 05/01/17 17:44, ipilc...@redhat.com wrote:

On Wednesday, October 5, 2016 at 4:13:48 AM UTC-5, Pierre Ossman wrote:

Alright. I'll have a look at doing the finishing touches. Thanks for the
patch. :)


FYI, there seems to be an issue with either the patch or v1.19 itself.

  https://bugzilla.redhat.com/show_bug.cgi?id=1408724



Urgh. I have no 1.19 system yet, so hopefully someone else can have a look.


I've been debugging this this afternoon, I believe I've identifief
the problem and I'm testing a fix now.

Regards,

Hans
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [tigervnc-devel] PATCH: Add xorg-xserver 1.19 support to tigervnc

[Pierre Ossman]

On 05/01/17 17:44, ipilc...@redhat.com wrote:

On Wednesday, October 5, 2016 at 4:13:48 AM UTC-5, Pierre Ossman wrote:

Alright. I'll have a look at doing the finishing touches. Thanks for the
patch. :)


FYI, there seems to be an issue with either the patch or v1.19 itself.

  https://bugzilla.redhat.com/show_bug.cgi?id=1408724



Urgh. I have no 1.19 system yet, so hopefully someone else can have a look.

Regards
--
Pierre Ossman   Software Development
Cendio AB   https://cendio.com
Teknikringen 8  https://twitter.com/ThinLinc
583 30 Linköpinghttps://facebook.com/ThinLinc
Phone: +46-13-214600https://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel