[PATCH xserver] glamor: Only force alpha to 1.0 inside RGBx source pictures

[Michel Dänzer]

From: Michel Dänzer 

We were forcing the alpha channel of RGBx source pictures to 1.0 for
all source coordinates. However, RENDER requires that sampling outside
of source picture boundaries generates alpha 0.0, regardless of whether
the source picture has an alpha channel or not.

May fix
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94514

Signed-off-by: Michel Dänzer 
---
 glamor/glamor_render.c | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index 65f7059..aef0758 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -105,7 +105,7 @@ glamor_create_composite_fs(struct shader_key *key)
 /* The texture and the pixmap size is not match eaxctly, so can't sample 
it directly.
  * rel_sampler will recalculate the texture coords.*/
 const char *rel_sampler =
-" vec4 rel_sampler(sampler2D tex_image, vec2 tex, vec4 wh, int 
repeat)\n"
+" vec4 rel_sampler_rgba(sampler2D tex_image, vec2 tex, vec4 wh, int 
repeat)\n"
 "{\n"
 "  if (repeat >= RepeatFix) {\n"
 "  tex = rel_tex_coord(tex, wh, repeat);\n"
@@ -117,6 +117,19 @@ glamor_create_composite_fs(struct shader_key *key)
 "  }\n"
 "  }\n"
 "  return texture2D(tex_image, tex);\n"
+"}\n"
+" vec4 rel_sampler_rgbx(sampler2D tex_image, vec2 tex, vec4 wh, int 
repeat)\n"
+"{\n"
+"  if (repeat >= RepeatFix) {\n"
+"  tex = rel_tex_coord(tex, wh, repeat);\n"
+"  if (repeat == RepeatFix + RepeatNone) {\n"
+"  if (tex.x < 0.0 || tex.x >= 1.0 || \n"
+"  tex.y < 0.0 || tex.y >= 1.0)\n"
+"  return vec4(0.0, 0.0, 0.0, 0.0);\n"
+"  tex = (fract(tex) / wh.xy);\n"
+"  }\n"
+"  }\n"
+"  return vec4(texture2D(tex_image, tex).rgb, 1.0);\n"
 "}\n";
 
 const char *source_solid_fetch =
@@ -131,8 +144,8 @@ glamor_create_composite_fs(struct shader_key *key)
 "uniform vec4 source_wh;"
 "vec4 get_source()\n"
 "{\n"
-"  return rel_sampler(source_sampler, source_texture,\n"
-" source_wh, source_repeat_mode);\n"
+"  return rel_sampler_rgba(source_sampler, source_texture,\n"
+"  source_wh, source_repeat_mode);\n"
 "}\n";
 const char *source_pixmap_fetch =
 "varying vec2 source_texture;\n"
@@ -140,9 +153,8 @@ glamor_create_composite_fs(struct shader_key *key)
 "uniform vec4 source_wh;\n"
 "vec4 get_source()\n"
 "{\n"
-"  return vec4(rel_sampler(source_sampler, source_texture,\n"
-"  source_wh, source_repeat_mode).rgb,\n"
-"  1.0);\n"
+"  return rel_sampler_rgbx(source_sampler, source_texture,\n"
+"  source_wh, source_repeat_mode);\n"
 "}\n";
 const char *mask_none =
 "vec4 get_mask()\n"
@@ -161,8 +173,8 @@ glamor_create_composite_fs(struct shader_key *key)
 "uniform vec4 mask_wh;\n"
 "vec4 get_mask()\n"
 "{\n"
-"  return rel_sampler(mask_sampler, mask_texture,\n"
-" mask_wh, mask_repeat_mode);\n"
+"  return rel_sampler_rgba(mask_sampler, mask_texture,\n"
+"  mask_wh, mask_repeat_mode);\n"
 "}\n";
 const char *mask_pixmap_fetch =
 "varying vec2 mask_texture;\n"
@@ -170,8 +182,8 @@ glamor_create_composite_fs(struct shader_key *key)
 "uniform vec4 mask_wh;\n"
 "vec4 get_mask()\n"
 "{\n"
-"  return vec4(rel_sampler(mask_sampler, mask_texture,\n"
-"  mask_wh, mask_repeat_mode).rgb, 1.0);\n"
+"  return rel_sampler_rgbx(mask_sampler, mask_texture,\n"
+"  mask_wh, mask_repeat_mode);\n"
 "}\n";
 
 const char *dest_swizzle_default =
-- 
2.8.0.rc3

___
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

[ANN] xdpyprobe 0.1

[Alex Kost]

Hello and sorry if this is not the proper place for this message.

I've written a small program to probe a connection to Xorg server
running on a particular $DISPLAY.  The source code looks a bit verbose,
but actually all it does is just a call of 'XOpenDisplay' and checking
the result.

As can be seen at
, when
people need to probe for avialable DISPLAY, they use general utilities
(like xset or xdpyinfo) which do many other things and produce unwanted
output, so I thought it might be handy to have a tool just to check a
connection.

Git repo: https://github.com/alezost/xdpyprobe

Initial release:

https://github.com/alezost/xdpyprobe/releases/download/v0.1/xdpyprobe-0.1.tar.gz
MD5: 7d378ff20ee76015feb35edd4f7ee469  xdpyprobe-0.1.tar.gz
SHA1: b5456cb6bbe424dcb70cac1413c0f232e6695731  xdpyprobe-0.1.tar.gz
sha256: 087f50a9015d4036ba22c9d3be91cc130680136c7b2a068bcc083c8645e309c0  
xdpyprobe-0.1.tar.gz

-- 
Thanks,
Alex
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Bug#819461: xserver-xorg-video-radeon: radeon 270x - no higher resolution that 1280x1024 possible

[Michel Dänzer]

On 29.03.2016 05:39, Tobias Koeck wrote:
> 
> DRM Information from dmesg:
> ---
> [0.389685] Linux agpgart interface v0.103
> [1.196300] ata1.00: supports DRM functions and may not be fully
> accessible
> [1.196627] ata1.00: supports DRM functions and may not be fully
> accessible
> [2.345019] [drm] Initialized drm 1.1.0 20060810
> [2.374580] [drm] radeon kernel modesetting enabled.
> [2.386694] [drm:radeon_pci_probe [radeon]] *ERROR* radeon kernel
> modesetting for R600 or later requires firmware-linux-nonfree.

Looks like you're missing the firmware-linux-nonfree /
firmware-amd-graphics package.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: [PATCH xserver v2] xwayland: Pretend we support viewport in vidmode

[Adam Jackson]

On Mon, 2016-03-21 at 10:19 +0100, Hans de Goede wrote:
> Hi,
> 
> On 21-03-16 09:53, Olivier Fourdan wrote:
> > 
> > Some games (namely openttd) will raise an XError and fail with a
> > BadValue if their request to XF86VidModeSetViewPort fails.
> > 
> > Support only the default zoom and viewport, fail for everything else.
> > 
> > Signed-off-by: Olivier Fourdan 
> Looks good to me:
> 
> Reviewed-by: Hans de Goede 

remote: I: patch #77609 updated using rev 
44e1c97ca6fe992bbb6ef9ecb0b82a113adfa57e.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   6e3a6e3..44e1c97  master -> master

- ajax
___
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 xserver] xwayland: do not include frequency in mode name

[Adam Jackson]

On Thu, 2016-03-17 at 15:09 +, Daniel Stone wrote:
> On 17 March 2016 at 13:39, Olivier Fourdan  wrote:
> > 
> > Some applications (e.g. using lwjgl) try to parse the output of the
> > xrandr command and get confused with the mode name returned by Xwayland,
> > because it contains "@[frequency]" (e.g. "1024x640@60.0Hz").
> > 
> > Remove the @[frequency] part of the mode name to match what is found in
> > usual mode names on regular X servers to please those applications.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94589
> > 
> > Signed-off-by: Olivier Fourdan 
> What a shame we can't yet legislate against stupidity.
> 
> Reviewed-by: Daniel Stone 

remote: I: patch #77287 updated using rev 
6e3a6e30a6ac66942a0756a5d079993181f02e34.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   418fe36..6e3a6e3  master -> master

- ajax
___
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: [ANNOUNCE] xorg-server 1.18.2

[Adam Jackson]

On Mon, 2016-03-28 at 14:02 -0400, Adam Jackson wrote:
> On Mon, 2016-03-28 at 17:35 +0900, Michel Dänzer wrote:
> 
> > Unfortunately, some of the backported fixes caused problems for users as
> > well, though some of those were not regressions as much as a fix
> > exposing pre-existing bugs elsewhere. (BTW,
> > https://patchwork.freedesktop.org/patch/78155/ is still pending to fix
> > such an issue)
> Merged:

Excuse me:

remote: I: patch #78155 updated using rev 
418fe365b45a143680d3b4143dc60f7cdc5a3507.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   adefbae..418fe36  master -> master

- ajax
___
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: [ANNOUNCE] xorg-server 1.18.2

[Adam Jackson]

On Mon, 2016-03-28 at 17:35 +0900, Michel Dänzer wrote:

> I can't help feeling that this went a bit overboard for a stable
> release. There are many changes in there which seem clearly or at least
> borderline features instead of fixes. If it's taking too long for new
> features to reach users, that would be better addressed by more frequent
> major releases instead.

I agree it was larger than I probably should have done. I did avoid
merging features that I thought were likely to be disruptive or that
would involve ABI changes, but I could have been stricter.

One challenge I face is trying to fill the role of both release manager
and reviewer of last resort. Absent much feedback about the quality of
merged patches, it can be difficult to distinguish "this looks sane
enough for my machine" and "this looks sane enough for everyone's
machine".

> Unfortunately, some of the backported fixes caused problems for users as
> well, though some of those were not regressions as much as a fix
> exposing pre-existing bugs elsewhere. (BTW,
> https://patchwork.freedesktop.org/patch/78155/ is still pending to fix
> such an issue)

Merged:



> Maybe there are some lessons to be learned from the Mesa release
> process, e.g.:
> 
> * There's a streamlined process for nominating changes to be backported
> from master to stable branches (via a specially formatted Cc: tag in the
> commit log which is parsed by a script to generate a list of changes to
> be backported; this scheme was inspired by the Linux kernel). The
> developer making a fix is usually in the best position to judge whether
> the fix should be backported to stable branches or not.
> 
> * There is soaking time (usually at least a week) between backporting
> changes to a stable branch and making a release. In contrast, for the
> xorg-server 1.18.2 release, I was already in the weekend when you first
> talked about backporting changes on IRC, and by the time my weekend was
> over, the release was already out.

I'm happy to adopt the Mesa process, sure. Honestly, I'd be happy if I
got _any_ comments about what might be appropriate for stable, or even
for master. The patch you cite above, for example, doesn't mention that
it addresses a regression (though admittedly the bz does). The number
of patches I've been cc'd on at all after review is probably less than
20. In the absence of that feedback I'm basically trusting my own
judgement. So yes, please do help me do better!

Compare the review stats for recent history for mesa and xserver:

dmt:~% topten() { grep ^Review | sort | uniq -c | sort -rnk1 | head -10 }
dmt:~% cd git/mesa
dmt:~/git/mesa% git log --oneline 11.2-branchpoint..master | wc -l  
755
dmt:~/git/mesa% git log 11.2-branchpoint..master | topten
 81 Reviewed-by: Marek Olšák 
 68 Reviewed-by: Dave Airlie 
 53 Reviewed-by: Ilia Mirkin 
 41 Reviewed-by: Nicolai Hähnle 
 34 Reviewed-by: Michel Dänzer 
 33 Reviewed-by: Matt Turner 
 33 Reviewed-by: Jordan Justen 
 32 Reviewed-by: Ian Romanick 
 32 Reviewed-by: Iago Toral Quiroga 
 31 Reviewed-by: Kenneth Graunke 
dmt:~% cd ../xserver
dmt:~/git/xserver% git log --oneline xorg-server-1.18.0..master | wc -l
252
dmt:~/git/xserver% git log xorg-server-1.18.0..master | topten
 79 Reviewed-by: Adam Jackson 
 26 Reviewed-by: Dave Airlie 
 25 Reviewed-by: Colin Harrison 
 20 Reviewed-by: Michel Dänzer 
 18 Reviewed-by: Kenneth Graunke 
 18 Reviewed-by: Eric Anholt 
 16 Reviewed-by: Keith Packard 
 12 Reviewed-by: Peter Hutterer 
  9 Reviewed-by: Rémi Cardona 
  6 Reviewed-by: Chris Wilson 

Of those 252 xserver patches I wrote only 34, and only four people
reviewed more than one of those 34. I have another 25 sent but
unreviewed. Patchwork has something like 130 patches open since 1.18
with (approximately, it doesn't quite know series r-bs) 32 reviews
total; of those 32 reviews only eight people reviewed more than one
patch (again, possibly an undercount due to series rbs).

Perhaps, in addition to a more formalized stable process, it would be
useful to get a report of the review status of various proposed patches
on a (say) weekly basis. That would be fairly easy to generate, and
might be a good context for people to ask questions about how reviews
should proceed: whether the concept is reasonable, how it interacts
with the rest of the server, etc.

- ajax

Re: [PATCH xserver] os: Treat ssh as a non-local client (v4)

[Adam Jackson]

On Mon, 2016-03-28 at 18:11 +0900, Michel Dänzer wrote:
> From: Adam Jackson 
> 
> By the time we get to ComputeLocalClient, we've already done
> NextAvailableClient → ReserveClientIds → DetermineClientCmd (assuming
> we're built with #define CLIENTIDS), so we can look up the name of the
> client process and refuse to treat ssh's X forwarding as if 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 only ignore path on Cygwin
>   (Martin Peres, Emil Velikov, Jon Turney)
> v4: (Michel Dänzer)
> * Cut of any colon and whatever comes after it. (Adam Jackson)
> * Add bugzilla reference.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93261
> 
> Signed-off-by: Adam Jackson 
> Signed-off-by: Michel Dänzer 

remote: I: patch #78481 updated using rev 
adefbaee499b9679c6cac21f52ec6545af2b36b5.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   1c90797..adefbae  master -> master

- ajax
___
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 xserver] DRI2: add Polaris PCI IDs

[Adam Jackson]

On Mon, 2016-03-28 at 10:06 -0400, Alex Deucher wrote:
> On Mon, Mar 28, 2016 at 3:36 AM, Michel Dänzer  wrote:
> > 
> > From: Sonny Jiang 
> > 
> > Signed-off-by: Sonny Jiang 
> > Reviewed-by: Alex Deucher  (Polaris10)
> > Reviewed-by: Michel Dänzer  (Polaris11)
> > 
> > (Ported from Mesa commit f00c840578a70e479ffb99f6b64c73dc420179fa)
> > 
> > Signed-off-by: Michel Dänzer 
> Reviewed-by: Alex Deucher 

remote: I: patch #78479 updated using rev 
1c90797565385426ad63bd2108085c8466695c0b.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   3b38510..1c90797  master -> master

- ajax
___
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 xf86-video-ati] DRI3: Refuse to open DRM file descriptor for ssh clients

[Alex Deucher]

On Mon, Mar 28, 2016 at 5:45 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> Fixes hangs when attempting to use DRI3 on display connections forwarded
> via SSH.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93261
> Signed-off-by: Michel Dänzer 

Reviewed-by: Alex Deucher 

> ---
>  src/radeon_dri3.c | 39 ++-
>  1 file changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/src/radeon_dri3.c b/src/radeon_dri3.c
> index 1415a0d..faaf4eb 100644
> --- a/src/radeon_dri3.c
> +++ b/src/radeon_dri3.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>
>  static int
> @@ -86,6 +87,38 @@ radeon_dri3_open(ScreenPtr screen, RRProviderPtr provider, 
> int *out)
> return Success;
>  }
>
> +#if DRI3_SCREEN_INFO_VERSION >= 1
> +
> +static int
> +radeon_dri3_open_client(ClientPtr client, ScreenPtr screen,
> +   RRProviderPtr provider, int *out)
> +{
> +   const char *cmdname = GetClientCmdName(client);
> +   Bool is_ssh = FALSE;
> +
> +   /* If the executable name is "ssh", assume that this client connection
> +* is forwarded from another host via SSH
> +*/
> +   if (cmdname) {
> +   char *cmd = strdup(cmdname);
> +
> +   /* Cut off any colon and whatever comes after it, see
> +* 
> https://lists.freedesktop.org/archives/xorg-devel/2015-December/048164.html
> +*/
> +   cmd = strtok(cmd, ":");
> +
> +   is_ssh = strcmp(basename(cmd), "ssh") == 0;
> +   free(cmd);
> +   }
> +
> +   if (!is_ssh)
> +   return radeon_dri3_open(screen, provider, out);
> +
> +   return BadAccess;
> +}
> +
> +#endif /* DRI3_SCREEN_INFO_VERSION >= 1 */
> +
>  static PixmapPtr radeon_dri3_pixmap_from_fd(ScreenPtr screen,
> int fd,
> CARD16 width,
> @@ -179,9 +212,13 @@ static int radeon_dri3_fd_from_pixmap(ScreenPtr screen,
>  }
>
>  static dri3_screen_info_rec radeon_dri3_screen_info = {
> +#if DRI3_SCREEN_INFO_VERSION >= 1
> +   .version = 1,
> +   .open_client = radeon_dri3_open_client,
> +#else
> .version = 0,
> -
> .open = radeon_dri3_open,
> +#endif
> .pixmap_from_fd = radeon_dri3_pixmap_from_fd,
> .fd_from_pixmap = radeon_dri3_fd_from_pixmap
>  };
> --
> 2.8.0.rc3
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-ati@lists.x.org
> https://lists.x.org/mailman/listinfo/xorg-driver-ati
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 94717] freezes upon system boot with kernel 4.2.0-30

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=94717

Alex Deucher  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Alex Deucher  ---
This has already been reverted upstream:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=256faedcfd646161477d47a1a78c32a562d2e845

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Re: [PATCH xserver] DRI2: add Polaris PCI IDs

[Alex Deucher]

On Mon, Mar 28, 2016 at 3:36 AM, Michel Dänzer  wrote:
> From: Sonny Jiang 
>
> Signed-off-by: Sonny Jiang 
> Reviewed-by: Alex Deucher  (Polaris10)
> Reviewed-by: Michel Dänzer  (Polaris11)
>
> (Ported from Mesa commit f00c840578a70e479ffb99f6b64c73dc420179fa)
>
> Signed-off-by: Michel Dänzer 

Reviewed-by: Alex Deucher 

> ---
>  hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h 
> b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> index bcf15a1..4df8e9d 100644
> --- a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> +++ b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> @@ -182,4 +182,14 @@ CHIPSET(0x9877, CARRIZO_, CARRIZO)
>
>  CHIPSET(0x7300, FIJI_, FIJI)
>
> +CHIPSET(0x67E0, POLARIS11_, POLARIS11)
> +CHIPSET(0x67E1, POLARIS11_, POLARIS11)
> +CHIPSET(0x67E8, POLARIS11_, POLARIS11)
> +CHIPSET(0x67E9, POLARIS11_, POLARIS11)
> +CHIPSET(0x67EB, POLARIS11_, POLARIS11)
> +CHIPSET(0x67FF, POLARIS11_, POLARIS11)
> +
> +CHIPSET(0x67C0, POLARIS10_, POLARIS10)
> +CHIPSET(0x67DF, POLARIS10_, POLARIS10)
> +
>  CHIPSET(0x98E4, STONEY_, STONEY)
> --
> 2.8.0.rc3
>
> ___
> 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: [PATCH xserver] xfree86: Immediately handle failure to set HW cursor

[Michel Dänzer]

On 28.03.2016 18:35, Alexandre Courbot wrote:
> On 03/23/2016 06:14 PM, Michael Thayer wrote:
>> Looks good at first quick glance (I am away from the computer a bit over
>> the Easter weeks, I will take another look when I am back).  One thing I
>> can say immediately though: when I submitted similar patches a while
>> back, Keith had the idea of keeping the old hooks untouched and adding
>> in the additional "checked" variants so that existing driver code does
>> not have to be changed to keep working.  The other thing is that this
>> might need a bump of ABI_XINPUT_VERSION.
> 
> Thanks for the comments. It has actually been suggested to me to define
> a new _checked() variant of the set_cursor hooks, but since this patch
> changes all the call sites I refrained from doing it. However your
> message sounds like there are users of these hooks outside the xserver
> package, is this correct? (sorry, I'm a complete X n00b).

Yes, these hooks are basically used by all drivers which support a HW
cursor.


> If so I will resend as you suggested, and also bump ABI_XINPUT_VERSION.

I don't think ABI_XINPUT_VERSION has anything to do with your patch, and
ABI_VIDEODRV_VERSION has already been bumped for this release cycle, so
you don't need to worry about that.


P.S. Please consider subscribing acour...@nvidia.com to this list, so
your posts don't go through the moderation queue. If you don't want to
receive list posts on that address, you can disable delivery in the
mailman preferences.

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

Re: [PATCH xserver] xfree86: Immediately handle failure to set HW cursor

[Alexandre Courbot]

Hi Michael,

On 03/23/2016 06:14 PM, Michael Thayer wrote:

Looks good at first quick glance (I am away from the computer a bit over
the Easter weeks, I will take another look when I am back).  One thing I
can say immediately though: when I submitted similar patches a while
back, Keith had the idea of keeping the old hooks untouched and adding
in the additional "checked" variants so that existing driver code does
not have to be changed to keep working.  The other thing is that this
might need a bump of ABI_XINPUT_VERSION.


Thanks for the comments. It has actually been suggested to me to define 
a new _checked() variant of the set_cursor hooks, but since this patch 
changes all the call sites I refrained from doing it. However your 
message sounds like there are users of these hooks outside the xserver 
package, is this correct? (sorry, I'm a complete X n00b).


If so I will resend as you suggested, and also bump ABI_XINPUT_VERSION.

Thanks!
Alex.

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
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 xf86-video-ati] DRI3: Refuse to open DRM file descriptor for ssh clients

[Michel Dänzer]

From: Michel Dänzer 

Fixes hangs when attempting to use DRI3 on display connections forwarded
via SSH.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93261
Signed-off-by: Michel Dänzer 
---
 src/radeon_dri3.c | 39 ++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/src/radeon_dri3.c b/src/radeon_dri3.c
index 1415a0d..faaf4eb 100644
--- a/src/radeon_dri3.c
+++ b/src/radeon_dri3.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 static int
@@ -86,6 +87,38 @@ radeon_dri3_open(ScreenPtr screen, RRProviderPtr provider, 
int *out)
return Success;
 }
 
+#if DRI3_SCREEN_INFO_VERSION >= 1
+
+static int
+radeon_dri3_open_client(ClientPtr client, ScreenPtr screen,
+   RRProviderPtr provider, int *out)
+{
+   const char *cmdname = GetClientCmdName(client);
+   Bool is_ssh = FALSE;
+
+   /* If the executable name is "ssh", assume that this client connection
+* is forwarded from another host via SSH
+*/
+   if (cmdname) {
+   char *cmd = strdup(cmdname);
+
+   /* Cut off any colon and whatever comes after it, see
+* 
https://lists.freedesktop.org/archives/xorg-devel/2015-December/048164.html
+*/
+   cmd = strtok(cmd, ":");
+
+   is_ssh = strcmp(basename(cmd), "ssh") == 0;
+   free(cmd);
+   }
+
+   if (!is_ssh)
+   return radeon_dri3_open(screen, provider, out);
+
+   return BadAccess;
+}
+
+#endif /* DRI3_SCREEN_INFO_VERSION >= 1 */
+
 static PixmapPtr radeon_dri3_pixmap_from_fd(ScreenPtr screen,
int fd,
CARD16 width,
@@ -179,9 +212,13 @@ static int radeon_dri3_fd_from_pixmap(ScreenPtr screen,
 }
 
 static dri3_screen_info_rec radeon_dri3_screen_info = {
+#if DRI3_SCREEN_INFO_VERSION >= 1
+   .version = 1,
+   .open_client = radeon_dri3_open_client,
+#else
.version = 0,
-
.open = radeon_dri3_open,
+#endif
.pixmap_from_fd = radeon_dri3_pixmap_from_fd,
.fd_from_pixmap = radeon_dri3_fd_from_pixmap
 };
-- 
2.8.0.rc3

___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[PATCH xserver] os: Treat ssh as a non-local client (v4)

[Michel Dänzer]

From: Adam Jackson 

By the time we get to ComputeLocalClient, we've already done
NextAvailableClient → ReserveClientIds → DetermineClientCmd (assuming
we're built with #define CLIENTIDS), so we can look up the name of the
client process and refuse to treat ssh's X forwarding as if 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 only ignore path on Cygwin
  (Martin Peres, Emil Velikov, Jon Turney)
v4: (Michel Dänzer)
* Cut of any colon and whatever comes after it. (Adam Jackson)
* Add bugzilla reference.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93261

Signed-off-by: Adam Jackson 
Signed-off-by: Michel Dänzer 
---
 os/access.c | 43 ---
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/os/access.c b/os/access.c
index 8b2177f..58f95a9 100644
--- a/os/access.c
+++ b/os/access.c
@@ -173,6 +173,10 @@ SOFTWARE.
 
 #endif  /* WIN32 */
 
+#if !defined(WIN32) || defined(__CYGWIN__)
+#include 
+#endif
+
 #define X_INCLUDE_NETDB_H
 #include 
 
@@ -1080,9 +1084,8 @@ ResetHosts(const char *display)
 }
 }
 
-/* Is client on the local host */
-Bool
-ComputeLocalClient(ClientPtr client)
+static Bool
+xtransLocalClient(ClientPtr client)
 {
 int alen, family, notused;
 Xtransaddr *from = NULL;
@@ -1115,6 +1118,40 @@ ComputeLocalClient(ClientPtr client)
 return FALSE;
 }
 
+/* Is client on the local host */
+Bool
+ComputeLocalClient(ClientPtr client)
+{
+const char *cmdname = GetClientCmdName(client);
+
+if (!xtransLocalClient(client))
+return FALSE;
+
+/* If the executable name is "ssh", assume that this client connection
+ * is forwarded from another host via SSH
+ */
+if (cmdname) {
+char **cmd;
+Bool ret;
+
+/* Cut off any colon and whatever comes after it, see
+ * 
https://lists.freedesktop.org/archives/xorg-devel/2015-December/048164.html
+ */
+cmd = xstrtokenize(cmdname, ":");
+
+#if !defined(WIN32) || defined(__CYGWIN__)
+cmd[0] = basename(cmd[0]);
+#endif
+
+ret = strcmp(cmd[0], "ssh") != 0;
+free(cmd);
+
+return ret;
+}
+
+return TRUE;
+}
+
 /*
  * Return the uid and all gids of a connected local client
  * Allocates a LocalClientCredRec - caller must call FreeLocalClientCreds
-- 
2.8.0.rc3

___
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: [ANNOUNCE] xorg-server 1.18.2

[Michel Dänzer]

Hi Adam,


first of all, thanks for merging changes to the master and stable
branches. The below is intended as constructive feedback.


On 12.03.2016 07:04, Adam Jackson wrote:
> A big pile of updates in this one. Highlights include:
> 
> - glamor is updated to use OpenGL core profiles if available, which
> should improve memory usage and performance on modern hardware, and got
> some other performance improvements for rpi and other GLES platforms
> 
> - DRI2, DRI3, and Present all received correctness fixes for hangs,
> crashes, and other weirdness
> 
> - Xwayland server has been updated to support the Xv and the
> xf86vidmode extensions for better compatibility, and fixed some bugs
> with output hotplug and pointer updates
> 
> - Xwin saw improvements to window and clipboard management, and a few
> new keyboard layouts
> 
> Full change list below. Many thanks to all for fixes and code review.

I can't help feeling that this went a bit overboard for a stable
release. There are many changes in there which seem clearly or at least
borderline features instead of fixes. If it's taking too long for new
features to reach users, that would be better addressed by more frequent
major releases instead.

Unfortunately, some of the backported fixes caused problems for users as
well, though some of those were not regressions as much as a fix
exposing pre-existing bugs elsewhere. (BTW,
https://patchwork.freedesktop.org/patch/78155/ is still pending to fix
such an issue)


Maybe there are some lessons to be learned from the Mesa release
process, e.g.:

* There's a streamlined process for nominating changes to be backported
from master to stable branches (via a specially formatted Cc: tag in the
commit log which is parsed by a script to generate a list of changes to
be backported; this scheme was inspired by the Linux kernel). The
developer making a fix is usually in the best position to judge whether
the fix should be backported to stable branches or not.

* There is soaking time (usually at least a week) between backporting
changes to a stable branch and making a release. In contrast, for the
xorg-server 1.18.2 release, I was already in the weekend when you first
talked about backporting changes on IRC, and by the time my weekend was
over, the release was already out.


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

[Bug 94712] second xserver has no connected output with radeon DIS

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=94712

--- Comment #3 from jydc...@21cn.com ---
Created attachment 122592
  --> https://bugs.freedesktop.org/attachment.cgi?id=122592=edit
dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 94712] second xserver has no connected output with radeon DIS

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=94712

--- Comment #4 from jydc...@21cn.com ---
Created attachment 122593
  --> https://bugs.freedesktop.org/attachment.cgi?id=122593=edit
Xorg.1.log

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 94712] second xserver has no connected output with radeon DIS

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=94712

--- Comment #2 from jydc...@21cn.com ---
(In reply to Michel Dänzer from comment #1)
> Please attach the Xorg log and the output of dmesg and xrandr corresponding
> to the problem.

My basic thouhgts is default xserver using intel+radoen by dri prime, start
second xsever just using one video card(intel or radeon) if needed. Both of two
xservers using the same physical display, whatever internal or external.

Here is my debug message when second xsever just using radeon card:

~$ DISPLAY=:1 xrandr
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
DVI-0 disconnected (normal left inverted right x axis y axis)
LVDS-1 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
VGA-1 disconnected (normal left inverted right x axis y axis)

~$ xrandr  (intel+radeon dri prime)
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
LVDS1 connected (normal left inverted right x axis y axis)
   1920x1200 60.00 +  59.9549.85  
   (...)
DP1 disconnected (normal left inverted right x axis y axis)
VGA1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 368mm x
207mm
   1920x1080 60.00*+
   (...)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

And dmesg & Xorg.1.log

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 94712] second xserver has no connected output with radeon DIS

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=94712

--- Comment #1 from Michel Dänzer  ---
Please attach the Xorg log and the output of dmesg and xrandr corresponding to
the problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 94720] multi monitoring in Ubuntu [AMD/ATI] [xorg] [xorg-edgers]

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=94720

--- Comment #1 from Michel Dänzer  ---
As you can see in the Xorg log, you're not using the radeon driver but the
generic fbdev driver.

Make sure the radeon kernel driver isn't still blacklisted from when fglrx was
installed. If that's not the problem, please attach the corresponding dmesg
output.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 94720] multi monitoring in Ubuntu [AMD/ATI] [xorg] [xorg-edgers]

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=94720

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #122581|text/plain  |application/zip
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[PATCH xserver] DRI2: add Polaris PCI IDs

[Michel Dänzer]

From: Sonny Jiang 

Signed-off-by: Sonny Jiang 
Reviewed-by: Alex Deucher  (Polaris10)
Reviewed-by: Michel Dänzer  (Polaris11)

(Ported from Mesa commit f00c840578a70e479ffb99f6b64c73dc420179fa)

Signed-off-by: Michel Dänzer 
---
 hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h 
b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
index bcf15a1..4df8e9d 100644
--- a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
+++ b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
@@ -182,4 +182,14 @@ CHIPSET(0x9877, CARRIZO_, CARRIZO)
 
 CHIPSET(0x7300, FIJI_, FIJI)
 
+CHIPSET(0x67E0, POLARIS11_, POLARIS11)
+CHIPSET(0x67E1, POLARIS11_, POLARIS11)
+CHIPSET(0x67E8, POLARIS11_, POLARIS11)
+CHIPSET(0x67E9, POLARIS11_, POLARIS11)
+CHIPSET(0x67EB, POLARIS11_, POLARIS11)
+CHIPSET(0x67FF, POLARIS11_, POLARIS11)
+
+CHIPSET(0x67C0, POLARIS10_, POLARIS10)
+CHIPSET(0x67DF, POLARIS10_, POLARIS10)
+
 CHIPSET(0x98E4, STONEY_, STONEY)
-- 
2.8.0.rc3

___
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

Missing letters after suspend

[martin f krafft]

Hi,

I am not sure the following is an X.org issue, but I hope you'll let
me start here.

Please see attached screenshot. This is on a laptop and occurs
occasionally after I bring the system back from suspend. Everything
works just fine, except certain letters (it's always a different set
it seems) are just not displaying.

At first I thought this is limited to GTK apps (Firefox,
Thunderbird, ssh-ask-pass, gscan2pdf), but I also see this with e.g.
the Awesome window manager, which does not link with GTK.

Have you encountered this before? What is going on? Which software
is at fault?

How can I fix this (without rebooting)?

Thank you!

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
#define emacs eighty megabytes and constantly swapping.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [PATCH xf86-video-ati] Revert "Use render node for DRI3 if available"

[Michel Dänzer]

On 25.03.2016 20:24, Andy Furniss wrote:
> Andy Furniss wrote:
>> Michel Dänzer wrote:
>>> From: Michel Dänzer 
>>>
>>> This reverts commit cd94248ffa7d8fe0b57476f79e7e860dee66d1b0.
>>>
>>> It broke VDPAU<->GL interop with DRI3 enabled, because the Gallium VDPAU
>>> code doesn't support DRI3 yet. We can consider re-enabling this once
>>> there is a Mesa release where the Gallium VDPAU code supports DRI3.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94675
>>
>> Hmm, curious why mpv and kodi vdpau interop seems to work fine for me
>> with DRI3.
> 
> Oops, I meant to reply to the amdgpu one rather than this.

Hmm, I guess libdrm_amdgpu does magic to make it work then. That leaves
the question whether we want to reinstate it for amdgpu now, or wait
until it can be reinstated for radeon as well. Unless somebody can think
of an important reason why render nodes should be used for DRI3 clients,
I'm leaning towards the latter.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati