Re: [PATCH xf86-video-amdgpu] Adapt to PixmapDirtyUpdateRec::src being a DrawablePtr

[Michel Dänzer]

On 13/07/17 05:27 PM, Michel Dänzer wrote:
> On 18/04/17 07:07 PM, Michel Dänzer wrote:
>> From: Michel Dänzer 
>>
>> Signed-off-by: Michel Dänzer 
>> ---
>>
>> Chris / Ilia / Ben, this should be manageable for the intel/nouveau
>> drivers, right?
> 
> Any feedback, guys?
> 
> I want to push the xserver change soon-ish. I could probably come up
> with a corresponding patch for nouveau in the worst case, but I'm afraid
> not for intel.

Chris,

in response to your bugzilla comment
https://bugs.freedesktop.org/show_bug.cgi?id=100086#c9 and patch
https://patchwork.freedesktop.org/patch/143180/, I drafted how the ABI
could be fixed to reflect current usage in the first comment to your
patch. There was no response in a month, so I went ahead and wrote
https://patchwork.freedesktop.org/patch/150938/ . After three months
with no feedback, I followed up with the ping above. After almost
another month without feedback from you, I pinged you about it on IRC,
again no response.

I'm afraid my patience has run out, I'll push the xserver patch next
week. Until the xf86-video-intel SNA driver is fixed up, it'll continue
being broken as the master screen driver with RandR 1.4 slave scanout.


-- 
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: Is this issue related with the bug 20048 , 17923 or 71338

[Adam Jackson]

On Fri, 2017-08-04 at 05:55 +, Subrata Dasgupta wrote:
> Hi Ajax,
> Why every time XErrorEvent.serial = 2422603788. Does not it mean
> application is facing problem only after a certain number of requests
> has been made??

It means the error structure points to a place in memory that
consistently contains that value, yes. But an XErrorEvent is only sent
for protocol errors, not disconnections, so I'm pretty sure that's just
a coincidence. To wit:

> Can you please provide where from I get information about the
> error_code, request_code and minor_codes of XErrorEvent structure
> because I want to understand the meaning of the following codes. 
> 
> XErrorEvent.error_code = 84
> XErrorEvent.request_code = 131 
> XErrorEvent.minor_code = 4

You can discover the mappings for these from 'xdpyinfo
-queryExtensions', which will list the error and event bases and
extension opcode for each extension. Extension codes are assigned
dynamically so this will depend on the specific server you're talking
to. On my machine:

% xdpyinfo -queryExtensions | grep 131
XInputExtension  (opcode: 131, base event: 66, base error: 129)

The "error code" is also used for event codes, and xinput does indeed
have a lot of events, but that reinforces my point. Extension events
are between 64 and 127, and extension errors are between 128 and 255.
This event says error_code = 84, which means (assuming you trust that
the XErrorEvent struct was pointing to valid data) that what you're
looking at is _not a protocol error_.

> For a huge X application this should not be a coincidence. Most
> importantly this behavior seems to be related with the bug 71338.
> When I checked my libxcb.so and libX11.so it seems 4 functions
> proposed for the fix for 71338(xcb_send_request64,
> xcb_discard_reply64, xcb_wait_for_reply64, xcb_poll_for_reply64) are
> present within the libxcb.so but libX11 do not use the function
> xcb_send_request64 or xcb_discard_reply64 within it. Why this is so
> ??

Those are the functions responsible for processing data from the
server, so of course they will be in the backtrace for any fatal
connection error.

- ajax
___
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 v2 xf86-video-dummy] Add glamor acceleration which enables native OpenGL support (v2)

[Adam Jackson]

On Sat, 2017-08-05 at 19:54 +0700, Antoine Martin wrote:

> With an nvidia driver, I get:
> [119367.649] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
> [119367.649] (II) Module glamoregl: vendor="X.Org Foundation"
> [119367.649]  compiled for 1.19.3, module version = 1.0.0
> [119367.649]  ABI class: X.Org ANSI C Emulation, version 0.4
> [119367.649] (II) glamor: OpenGL accelerated X.org driver based.
> [119367.654] (II) glamor: EGL version 1.4 (DRI2):
> [119367.654] EGL_MESA_drm_image required.
> [119367.654] (EE) DUMMY(0): glamor initialization failed

This is expected, in the sense that glamor does indeed require
EGL_MESA_drm_image at the moment. But it need not, as far as I can
tell; the EGLImage stuff is only for dri3 buffer import/export, so in
principle glamor could be fixed to just not expose dri3 when that extn
isn't available.

> And with modesetting or intel drivers:
> [   738.822] (II) glamor: OpenGL accelerated X.org driver based.
> [   738.827] (II) glamor: EGL version 1.4 (DRI2):
> [   738.836] (II) DUMMY(0): glamor initialized
> [   738.836] (--) Depth 24 pixmap format is 32 bpp
> [   738.957] (II) DUMMY(0): Using 3904 scanlines of offscreen memory
> [   738.957] (==) DUMMY(0): Backing store enabled
> [   738.957] (==) DUMMY(0): Silken mouse enabled
> [   738.957] (==) RandR enabled
> [   738.959] (II) SELinux: Disabled by boolean
> [   738.960] (II) AIGLX: Screen 0 is not DRI2 capable
> [   738.960] (EE) AIGLX: reverting to software rendering
> 
> And in both cases, glxinfo reports that my dummy screen uses software
> rendering. (Accelerated: no, Gallium 0.4 on llvmpipe..)

This is also expected: the patch series only enables the use of GL for
the server's 2D rendering, it doesn't magically make 3D accel start
working. (I do have a series I'm working on to make glamor-enabled
drivers use the same EGL backend for GLX too, after which this would
work like you expect.)

> What am I doing wrong?

Nothing besides holding reasonable-but-invalid expectations. ;)

- 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

[PATCH xserver] meson: Fix epoll detection

[Peter Harris]

The epoll code depends on epoll_create1, not epoll_create.

The trinary " ? 1 : false" is used because HAVE_EPOLL_CREATE1 is tested
with #if instead of #ifdef.

Signed-off-by: Peter Harris 
---
 include/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/meson.build b/include/meson.build
index 78ec521ac..850c140fa 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -110,7 +110,7 @@ conf_data.set('HAVE_UNISTD_H', cc.has_header('unistd.h'))
 conf_data.set('HAVE_ARC4RANDOM_BUF', cc.has_function('arc4random_buf', 
dependencies: libbsd_dep))
 conf_data.set('HAVE_BACKTRACE', cc.has_function('backtrace'))
 conf_data.set('HAVE_CBRT', cc.has_function('cbrt'))
-conf_data.set('HAVE_EPOLL_CREATE', cc.has_function('epoll_create'))
+conf_data.set('HAVE_EPOLL_CREATE1', cc.has_function('epoll_create1') ? 1 : 
false)
 conf_data.set('HAVE_FFS', cc.has_function('ffs'))
 conf_data.set('HAVE_GETUID', cc.has_function('getuid'))
 conf_data.set('HAVE_GETEUID', cc.has_function('geteuid'))
-- 
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 xserver 0/1] Good bye GlxSetVisualConfigs

[Emil Velikov]

On 3 August 2017 at 16:54, Keith Packard  wrote:
> Emil Velikov  writes:
>
>> Thank you Alex.
>>
>> Considering the low interest on the driver side, I'm thinking about
>> merging those in the next 3 days/a week.
>> Thus at a later stage Adam/others can pull the Xserver patch, without
>> breaking the world.
>>
>> How does it sound?
>
> Sounds like a good plan.
>
Thanks Keith, I've pushed the driver patches.

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