Re: [PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

[Emil Velikov]

On 13 March 2017 at 17:07, Adam Jackson  wrote:
> On Fri, 2017-03-10 at 23:23 +, Emil Velikov wrote:
>> > On 10 March 2017 at 16:32, Adam Jackson  wrote:
>> > I neither expect nor want this to happen. dummy might have some minor
>> > utility, but the nested driver I think is a mistake, and I would not
>> > consider its availability as a reason to drop Xnest or Xephyr.
>> >
>>
>> Pardon the silly question, but going through the discussions did now help 
>> much.
>> Do we have a list of features/bugs for/against each suggestion ?
>
> I don't know what you mean by "each suggestion".
>
Pardon about that one - silly me being too brief, as always.

With "each suggestion" i meant "Xnest/Xephyr/xf86-video-{dummy,nested}
and other DDX/video drivers mentioned in this and earlier
discussions". Some information even if it covers only some of these
will also be appreciated.

>> I mean if there is somethings clearly defined, divide and conquer is the way.
>> Atm everything seems quite magical, unless one has extensive prior
>> experience with the DDXen and respective drivers.
>
> I don't know what you mean by "everything".
>
Your earlier reply mentioned that [you think that] xf86-video-nested
was a mistake without providing any justification why. It would be
great to have some information what is broken and/or architecturally
wrong with it or the other components mentioned just above.

IIRC the only issues [with Xorg] pointed out so far were a) memory
consumption and b) providing a config file [via command line as
non-root]. With the latter being resolved IIRC.

There's surely something else which has been pointed out/comes to your
mind, but is not obvious without spending 30+ minutes searching for
and/or through threads for the details.

Having those clearly defined, albeit overdue, is what we want, right ?

Thanks
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

Re: Video tearing with modesetting driver and Intel Sandybridge graphics

[Michel Dänzer]

On 15/03/17 06:31 PM, Tino Mettler wrote:
> On Wed, Mar 15, 2017 at 18:13:09 +0900, Michel Dänzer wrote:
>> Same problem with fullscreen and windowed?
> 
> I can't really tell. The tearing happens in the upper part of the
> screen. When moving the mpv window to the top of the screen, the
> location where tearing happens in fullscreen mode is occupied by the
> titlebar of the mpv window.

Please provide the Xorg log file from the modesetting driver.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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 xserver] glamor: Fix dashed line rendering.

[Michel Dänzer]

On 16/03/17 10:24 AM, Eric Anholt wrote:
> We were binding the screen pixmap as the dash and sampling its alpha,
> which is usually just 1.0 (no dashing at all).
> 
> Please cherry-pick this to active stable branches.
> 
> Signed-off-by: Eric Anholt 
> ---
>  glamor/glamor_dash.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/glamor/glamor_dash.c b/glamor/glamor_dash.c
> index 3c19dba323c7..f3cf749a6785 100644
> --- a/glamor/glamor_dash.c
> +++ b/glamor/glamor_dash.c
> @@ -146,7 +146,7 @@ glamor_dash_setup(DrawablePtr drawable, GCPtr gc)
>  goto bail;
>  
>  dash_pixmap = glamor_get_dash_pixmap(gc);
> -dash_priv = glamor_get_pixmap_private(pixmap);
> +dash_priv = glamor_get_pixmap_private(dash_pixmap);
>  
>  if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(dash_priv))
>  goto bail;
> 

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

Re: [PATCH xserver] glamor: Fix dashed line rendering.

[Keith Packard]

Eric Anholt  writes:

> We were binding the screen pixmap as the dash and sampling its alpha,
> which is usually just 1.0 (no dashing at all).
>
> Please cherry-pick this to active stable branches.
>
> Signed-off-by: Eric Anholt 

Thank you for finding this!

Reviewed-by: Keith Packard 

Now, can you explain why it ever did anything reasonable at all?

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

opengl and drm on a pi 3b?

[Gene Heskett]

Hello all, been a while since I rang your doorbell, greetings from West 
Virginia;

I am in the process of converting an old lathe to cnc, and using a pi 3b 
as the driver.

Doing some work on the configuration today, I got curious to see if the 
features I was adding to the configuration were pushing the poor pi to 
the point of exhaustion. Firing up htop, the various bits and pieces 
that together make up linuxcnc, were a total of about 4 or 5% of the cpu 
load.  Compton, the x compositor, was burning something in the region of 
165%, or a little over 1.5 of its 4 cores. It was also a few megabytes 
into swap, so I rebooted it, after which compton was only using perhaps 
35% of one core.

But my main reason for posting is to see if any progress is being made on 
opengl and drm drivers for that bcm video the pi has.  The display is 
just slow enough to be noticeable.  The machine its driving can move at 
up to about 100 inches a minute, with bone breaking force, so it would 
be a definite safety advantage if the video could keep up with the 
machine in something resembling real time.

So what, if any, is the status of faster video drivers for the pi's that 
use the bcm video?

Thanks all.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
___
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

[PATCH xserver] glamor: Fix dashed line rendering.

[Eric Anholt]

We were binding the screen pixmap as the dash and sampling its alpha,
which is usually just 1.0 (no dashing at all).

Please cherry-pick this to active stable branches.

Signed-off-by: Eric Anholt 
---
 glamor/glamor_dash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/glamor/glamor_dash.c b/glamor/glamor_dash.c
index 3c19dba323c7..f3cf749a6785 100644
--- a/glamor/glamor_dash.c
+++ b/glamor/glamor_dash.c
@@ -146,7 +146,7 @@ glamor_dash_setup(DrawablePtr drawable, GCPtr gc)
 goto bail;
 
 dash_pixmap = glamor_get_dash_pixmap(gc);
-dash_priv = glamor_get_pixmap_private(pixmap);
+dash_priv = glamor_get_pixmap_private(dash_pixmap);
 
 if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(dash_priv))
 goto bail;
-- 
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: [Intel-gfx] [ANNOUNCE] intel-gpu-tools 1.18

[Jani Nikula]

On Mon, 13 Mar 2017, Petri Latvala  wrote:
> A new intel-gpu-tools quarterly release is available with the
> following changes:

> Jason Ekstrand (1):
>   aubdump: Support EXECBUFFER2_WR

I'm rather annoyed because this wasn't sent to the intel-gfx list
AFAICT, there was previous discussion about it needing configure support
[1], it breaks the build for me, and it was now released.

/me walks away from keyboard before I end up pushing a revert without
sending it to the list first. :(

BR,
Jani.


[1] 
http://mid.mail-archive.com/20170130142047.7838-1-lionel.g.landwerlin@intel.com

-- 
Jani Nikula, Intel Open Source Technology Center
___
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: [Intel-gfx] [ANNOUNCE] intel-gpu-tools 1.18

[Jani Nikula]

On Mon, 13 Mar 2017, Petri Latvala  wrote:
> A new intel-gpu-tools quarterly release is available with the
> following changes:

> Jason Ekstrand (1):
>   aubdump: Support EXECBUFFER2_WR

I'm rather annoyed because this wasn't sent to the intel-gfx list
AFAICT, there was previous discussion about it needing configure support
[1], it breaks the build for me, and it was now released.

/me walks away from keyboard before I end up pushing a revert without
sending it to the list first. :(

BR,
Jani.


[1] 
http://mid.mail-archive.com/20170130142047.7838-1-lionel.g.landwerlin@intel.com

-- 
Jani Nikula, Intel Open Source Technology Center
___
xorg-announce mailing list
xorg-announce@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-announce

Re: [PATCH xdriinfo] Fix xdriinfo not working with glvnd

[Eric Anholt]

Hans de Goede  writes:

> For glx calls to work on libglvnd as glx provider we must first call
> glXGetClientString. This also means that we can no longer take the
> shortcut to not open the Display when a driver name is past to options.

This seems sensible.  Hopefully nothing is relying on this working
without an X connection being possible.

Reviewed-by: Eric Anholt 


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: [PATCH xserver 1/4] xfree86: Remove 24bpp pixmap format support (v2)

[Eric Anholt]

Adam Jackson  writes:

> There's really no reason to pretend to support this, apps hate it, all
> we're doing is giving people a way to injure themselves. It doesn't work
> anyway with any Radeon, any NVIDIA chip, or any Intel chip since i810.
> Rip out all the logic for handling 24bpp pixmaps and framebuffers, and
> silently ignore the old options that would ask for it.
>
> The cirrus alpine driver has been updated to default to 16bpp, and both
> it and the i810 driver can now use the 32->24 conversion code in shadow
> if they want. All other drivers support 32bpp. Configurations that
> explicitly request 24bpp in order to fit in VRAM will be broken now
> though.

I am so happy to see all this ugly code gone.  Series is:

Reviewed-by: Eric Anholt 


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: [PATCH xserver] glamor: Paint first and last pixel of lines

[Eric Anholt]

Keith Packard  writes:

> [ Unknown signature status ]
> Adam Jackson  writes:
>
>> Is there some reason you believe GL's rasterisation rules for lines
>> match fb's zero-width lines? Section 14.5.1 of the 4.5 spec looks quite
>> a bit looser than fb to me.
>
> I think they're 'good enough'; there aren't any rules requiring
> particular rasterization for either, the only thing X requests is that
> 'not last' cap mode not draw the last pixel. afaict, GL suggests 'not
> last' as the only option. It sounds like some drivers are doing both
> 'not last' and 'not first' though?

By "some drivers" we mean i965, it seems.  The problem is that we're not
getting 0-width, specified-under-DirectX lines.  We've got glLineWidth
== 1, so we're getting the garbage "let's turn it into a polygon with
major-axis-aligned ends!" behavior.  Thanks to glamor's +0.5 translation
based on the assumption that we were drawing 0-width lines, we now have
a polygon whose start and end lie on pixel centers (other than float
rounding), for bonus unstable behavior.  If you go into i965 and program
line width to 0, everything's great.

And, if you read the GL spec, it talks a bunch about the diamond exit
rule, which would only make sense if you could actually ask for 0-width
lines.  Thanks, Khronos.

Looking at vc4, it doesn't even have 0-width line behavior, and does
even worse at this testcase.

I'm thinking we need to specify an extension allowing glLineWidth(0) for
diamond exit rule, maybe with a hint to choose between the dx9 and dx10
modes.  Then glamor could check for it and use GL, and fall back to mi
otherwise.


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: [PATCH xf86-input-libinput] Support for rel+abs composite devices on the same node

[Peter Hutterer]

On Sat, Mar 11, 2017 at 12:26:38PM +0100, Gergely Nagy wrote:
> Largely based on work by Peter Hutterer, this patch makes composite relative +
> absolute devices work with the driver. Such devices are anything that presents
> itself as both a mouse, and - for example - a touch screen, like the 
> Keyboardio
> Model 01 (or anything that uses Nico Hood's HID library for Arduino).
> 
> If a device has both capabilities present, we split them into two separate
> devices for X (see xf86libinput_pre_init()), like we do with the composite
> keyboard + mouse devices. Then, we route absolute events to the absolute
> subdevice (see xf86libinput_pick_device()). The rest of the patch is mostly
> small updates to support the newly introduced CAP_POINTER_ABSOLUTE flag.
> 
> There's one missing thing, however: event routing for buttons. At the moment,
> button routing is simply not done, but in practice, this does not seem to have
> any ill side effects.

Most likely because the buttons are merged in the virtual core pointer in X.
But to an XI2 application they still look different which may cause some
problems down the road.

I think the best option here is to route BTN_LEFT to exclusing BTN_JOYSTICK
through the relative device and all others through the absolute device. Any
device that needs special routing can be fixed as it comes.

Cheers,
   Peter

> 
> https://bugs.freedesktop.org/show_bug.cgi?id=99914
> 
> Signed-off-by: Gergely Nagy 
> ---
>  src/xf86libinput.c | 81 
> ++
>  1 file changed, 58 insertions(+), 23 deletions(-)
> 
> diff --git a/src/xf86libinput.c b/src/xf86libinput.c
> index 888c8f2..a099c5b 100644
> --- a/src/xf86libinput.c
> +++ b/src/xf86libinput.c
> @@ -87,6 +87,7 @@
>  #define CAP_TABLET   0x8
>  #define CAP_TABLET_TOOL  0x10
>  #define CAP_TABLET_PAD   0x20
> +#define CAP_POINTER_ABSOLUTE 0x40
>  
>  struct xf86libinput_driver {
>   struct libinput *libinput;
> @@ -805,6 +806,20 @@ xf86libinput_init_pointer_absolute(InputInfoPtr pInfo)
>   Atom btnlabels[MAX_BUTTONS];
>   Atom axislabels[TOUCHPAD_NUM_AXES];
>  
> + /* We always initialize rel as parent on absrel devices */
> + if (xf86libinput_is_subdevice(pInfo)) {
> + /*
> +  * FIXME: well, we can't really know which buttons belong to
> +  * which device here, but adding it to both doesn't make
> +  * sense either. Options are: assume LMR is on rel, BTN_0
> +  * and friends on absolute. That's not always correct but
> +  * that's as best as we can do.
> +  *
> +  * FIXME: event routing for buttons isn't set up correctly
> +  * yet.
> +  */
> + }
> +
>   for (i = BTN_BACK; i >= BTN_SIDE; i--) {
>   if (libinput_device_pointer_has_button(device, i)) {
>   nbuttons += i - BTN_SIDE + 1;
> @@ -1179,13 +1194,10 @@ xf86libinput_init(DeviceIntPtr dev)
>  
>   if (driver_data->capabilities & CAP_KEYBOARD)
>   xf86libinput_init_keyboard(pInfo);
> - if (driver_data->capabilities & CAP_POINTER) {
> - if (libinput_device_config_calibration_has_matrix(device) &&
> - !libinput_device_config_accel_is_available(device))
> - xf86libinput_init_pointer_absolute(pInfo);
> - else
> - xf86libinput_init_pointer(pInfo);
> - }
> + if (driver_data->capabilities & CAP_POINTER)
> + xf86libinput_init_pointer(pInfo);
> + if (driver_data->capabilities & CAP_POINTER_ABSOLUTE)
> + xf86libinput_init_pointer_absolute(pInfo);
>   if (driver_data->capabilities & CAP_TOUCH)
>   xf86libinput_init_touch(pInfo);
>   if (driver_data->capabilities & CAP_TABLET_TOOL)
> @@ -1347,7 +1359,7 @@ xf86libinput_handle_absmotion(InputInfoPtr pInfo, 
> struct libinput_event_pointer
>   return;
>   }
>  
> - if ((driver_data->capabilities & CAP_POINTER) == 0)
> + if ((driver_data->capabilities & CAP_POINTER_ABSOLUTE) == 0)
>   return;
>  
>   x = libinput_event_pointer_get_absolute_x_transformed(event, 
> TOUCH_AXIS_MAX);
> @@ -1368,7 +1380,7 @@ xf86libinput_handle_button(InputInfoPtr pInfo, struct 
> libinput_event_pointer *ev
>   int button;
>   int is_press;
>  
> - if ((driver_data->capabilities & CAP_POINTER) == 0)
> + if ((driver_data->capabilities & (CAP_POINTER|CAP_POINTER_ABSOLUTE)) == 
> 0)
>   return;
>  
>   button = btn_linux2xorg(libinput_event_pointer_get_button(event));
> @@ -1493,7 +1505,7 @@ xf86libinput_handle_axis(InputInfoPtr pInfo, struct 
> libinput_event_pointer *even
>   double value;
>   enum libinput_pointer_axis_source source;
>  
> - if ((driver_data->capabilities & CAP_POINTER) == 0)
> + if ((driver_data->capabilities & (CAP_POINTER|CAP_POINTER_ABSOLUTE)) == 
> 

Re: RandR 1.5 "Monitors" and splitting a single physical display

[Aaron Plattner]

On 03/13/2017 11:32 AM, Nathan Schulte wrote:
> On 03/07/2017 05:56 PM, Jack Coulter wrote:
>> Is it possible for there to be multiple monitors for a single output, at
>> least as far as the RandR protocol is concerned, and is support simply
>> needed in xrandr, or is what I'm trying to do simply not possible?
> 
> I wonder the same; I'm looking to split an Output as two Monitors, and
> then rotate one of the Monitors.  I am using an active splitter, like
> Jack is w/ the Matrox Dual Head 2 Go devices (I'm using a Sunix DPD2001,
> with DisplayPort Multi-Stream Transport disabled).

You're not going to be able to rotate one monitor with the existing protocol. 
Rotation happens at the crtc, not the output or monitor.

> I ran into issues trying to do setup multiple Monitors for an Output,
> and sent a mail to the list in September 2016; Aaron Plattner from
> NVIDIA responded, noting about the "ConnectionNumber" property from the
> xrandr --prop command.  The Intel hardware I'm using (Intel Skylake;
> Iris Pro Graphics P580 [8086:193d] (rev 09).
> 
> The thread can be viewed here:
> 
> https://lists.x.org/archives/xorg/2016-September/058245.html
> 
> I had to give up at the time and still haven't had a chance to poke this
> again.  I have a feeling this isn't supported, but I couldn't find
> anything in the protocol/extension specifications stating so.  In fact,
> the specs imply that it _is_ indeed possible.  Perhaps only certain
> drivers provide this level of support?
> 
> Jack, let me know if you figure this out, please and thank you!

From the protocol, it sounds like it makes a distinction between monitors with 
outputs in them and monitors without.

Output-ful monitors have their geometry set automatically:

If 'info.outputs' is non-empty, and if x, y, width, height are all
zero, then the Monitor geometry will be dynamically defined to
be the bounding box of the geometry of the active CRTCs
associated with them.

But you can create a monitor with zero outputs and set its geometry manually.

The auto-delete behavior sounds carefully worded to only apply when removing an 
output from a output-ful monitor, and leaves monitors that never had outputs 
alone:

For each output in 'info.outputs, each one is removed from all
pre-existing Monitors. If removing the output causes the list of
outputs for that Monitor to become empty, then that Monitor will
be deleted as if RRDeleteMonitor were called.

So for this, I would imagine that you would want to create two monitors, both 
with no outputs, that just happen to overlap the output you want to split.

-- Aaron
___
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: `pkg-config --static --libs x11` unusable for static linking?

[xorg]

On Wed, Mar 15, 2017 at 02:01:06PM +0100, walter harms wrote:
> you are aware the glibc does not support static linking ?
> 
> re,
>  wh

The glibc caveats surrounding static linking are completely orthogonal to
what is happening here.  The library order in the link phase matters and
`pkg-config --static --libs x11` is outputting options both incomplete and
ordered incorrectly.

The value of static linking in this case is producing a binary which
doesn't require graphical dependencies to be installed on what may
otherwise be headless systems having little more than glibc and ssh
installed.

Please note that the smoke test below passes, after using the fixed up link
command mentioned previously to produce the static binary, with glibc on
debian jessie amd64:

# mkdir /tmp/foo
# mkdir /tmp/foo/tmp
# mount --bind /tmp /tmp/foo/tmp # for X socket
# mkdir /tmp/foo/proc
# mount --bind /proc /tmp/foo/proc # what the program monitors
# mkdir /tmp/foo/home
# mount --bind /home /tmp/foo/home # for ~/.Xauthority and static test program
# chroot /tmp/foo /tmp/foo/home/vc/src/vmon-static

The program works just fine in that ad-hoc root with absolutely zero .so
dependencies present, there isn't an /etc/nsswitch.conf, this is desirable.
This program may be run on any amd64 linux box to successfully monitor it
without any concern for what is installed, even tunneled over `ssh -X`
provided the DISPLAY environment variable is amended to use 127.0.0.1
instead of localhost to avoid the name resolution glibc caveat.

There's also the musl-libc route for when glibc's dynamic dependencies are
unignorable, but this is all off-topic.  This is fundamentally about static
linking the X dependencies, not glibc.

It would be appreciated if `pkg-config --static --libs x11` actually output
a usable set of flags.  Playing libc roullette is completely orthogonal and
a decision left up to the user not us, and the current situation blocks
users from even taking a spin.  It turns out the odds of winning are
actually in the user's favor, why are we interfering?  Is it so difficult
to make pkg-config output the correct things?  Isn't this the whole point
of pkg-config?

Regards,
Vito Caputo
___
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 xserver] xinerama: Implement graphics exposures for window->pixmap copies (v4)

[Adam Jackson]

On Wed, 2016-11-02 at 12:49 -0400, Adam Jackson wrote:
> This code is using GetImage to accumulate a logical view of the window
> image (since the windows will be clipped to their containing screen),
> and then PutImage to load that back into the pixmap.  What it wasn't
> doing was constructing a region for the obscured areas of the window and
> emitting graphics exposures for same.
> 
> v2: Fix coordinate translation when the source is the root window
> v3: Create sourceBox with the right coordinates initially instead of
> translating (Keith Packard)
> v4: Clamp the region to 15 bits to avoid overflow (Keith Packard)
> 
> Signed-off-by: Adam Jackson 

Right, been iterating on this patch since September 2014, I'm tired of
waiting. Merged sans further review:

remote: I: patch #119683 updated using rev 
e337de2d488a124e5fee0fdcb882567b68f1767d.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   f1f865e..e337de2  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 RFC xserver 0/2] glamor pixmap FBO array can be NULL

[Adam Jackson]

On Wed, 2017-03-15 at 15:55 -0400, Adam Jackson wrote:
> On Tue, 2017-03-14 at 14:58 +0100, Olivier Fourdan wrote:
> 
> > There are some cases where we don't have a fallback code path, in which
> > case we'll avoid the crash in glamor_set_destination_drawable() but won't
> > render properly, but this is a rare occurence and not rendering properly
> > is still better than crashing the X server and the user losing his/her
> > entire session...
> 
> Discarding rendering on allocation failure is fine, yeah. Or at any
> rate fb and mi already have that property.
> 
> 2/2 doesn't seem to check all the glamor_set_destination_drawable calls
> though (see: glamor_glyphs_flush, glamor_dash_loop, glamor_text,
> glamor_xv_render). Just an oversight?

Pushed anyway, easy enough to fix more spots later:

remote: I: patch #143942 updated using rev 
04b4bad7c048fd077fe839f10634c99ef1e488af.
remote: I: patch #143944 updated using rev 
455051a0f1d2bc84f605c325f647bd64d414c47d.
remote: I: 2 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   b0ce1d0..455051a  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 RFC xserver 0/2] glamor pixmap FBO array can be NULL

[Adam Jackson]

On Tue, 2017-03-14 at 14:58 +0100, Olivier Fourdan wrote:

> There are some cases where we don't have a fallback code path, in which
> case we'll avoid the crash in glamor_set_destination_drawable() but won't
> render properly, but this is a rare occurence and not rendering properly
> is still better than crashing the X server and the user losing his/her
> entire session...

Discarding rendering on allocation failure is fine, yeah. Or at any
rate fb and mi already have that property.

2/2 doesn't seem to check all the glamor_set_destination_drawable calls
though (see: glamor_glyphs_flush, glamor_dash_loop, glamor_text,
glamor_xv_render). Just an oversight?

- 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 0/2] Check initial screen resources creations in Xephyr

[Adam Jackson]

On Wed, 2017-03-15 at 10:23 +0900, Michel Dänzer wrote:
> On 14/03/17 11:22 PM, Olivier Fourdan wrote:
> > On startup, Xephyr does not check for the successful creation of its
> > screen pixmap, and would crash if it fails.
> > 
> > The following patches aim at exiting cleanly instead of segfaulting
> > if the screen pixmap creation fails, with glamor.
> > 
> > This was reported in downstream bug https://bugzilla.redhat.com/1431633
> > 
> > Cheers,
> > Olivier
> > 
> > Olivier Fourdan (2):
> >   glamor: Check for NULL pixmap in glamor_get_pixmap_texture()
> >   Xephyr: Check screen resources creation success
> 
> Both patches are
> 
> Reviewed-by: Michel Dänzer 

remote: I: patch #143945 updated using rev 
f40ff18c96e02ff18a367bf53feeb4bd8ee952a0.
remote: I: patch #143946 updated using rev 
b0ce1d088a863492f5de11e4dbde10af4261d892.
remote: I: 2 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   646bc74..b0ce1d0  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: Attach Touchscreen to X Screen

[Boszormenyi Zoltan]

Hi,

Read man xinput, see option map-to-output.

Then you can query the transformation matrix using xinput and
use the values in an xorg.conf piece, like these below so they are
applied as soon as the X server starts. This example works for
two X displays with identical resolutions side by side.

Section "InputClass"
Identifier "INTERNAL_TS"
MatchIsTouchscreen "on"
MatchProduct "EETI eGalaxTouch Serial TouchScreen"
Option "TransformationMatrix" "0.5 0 0 0 1 0 0 0 1"
EndSection

# Explicitly match only the Product name
# Neither MatchIsTouchscreen, MatchIsTouchpad or MatchIsTablet matches this 
device
Section "InputClass"
Identifier "ELO_TS"
MatchProduct "Elo TouchSystems, Inc. Elo TouchSystems 2700 IntelliTouch(r) 
USB"
Option "TransformationMatrix" "0.5 0 0.5 0 1 0 0 0 1"
EndSection

2017-03-15 15:50 keltezéssel, Mike Werner írta:

Hi,

I need to run multiple touch screens on an OpenSuSE 13.2 system, as well as on an Ubuntu 
16.04. Every thing works „fine“ when the system only has one graphics card (Nvidia) 
installed. Unfortunately the systems is required to provide two graphics cards. In this 
case the system has two XScreens and my approach mapping the xinput ID to a display port 
does not work any longer. It seems that xinput is only able to work properly with one 
xscreen (i.e. screen 0).


Is there a way to have multiple touch screens connected to multiple graphics cards? How 
can this be achieved?


*
Kind regrads

Mike
*

--
This message has been scanned for viruses and
dangerous content by *MailScanner* , and is
believed to be clean.


___
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



___
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

[ANNOUNCE] xorg-server 1.19.3

[Adam Jackson]

A couple more minor fixes, most notably a revert of a page-flipping
change that regressed some drivers.

Adam Jackson (2):
  Revert "present: Allow flipping with PRIME slave outputs"
  xserver 1.19.3

Chris Wilson (2):
  Revert "prime: Sync shared pixmap from root window instead of screen 
pixmap"
  os: Fix iteration over busfaults

Dr.-Ing. Dieter Jurzitza (1):
  glamor: Fix missing declaration in dash vertex shader

Olivier Fourdan (2):
  xwayland: clear cursor frame callback
  xwayland: Monitor client states to destroy callbacks

Qiang Yu (1):
  present: disable page flip only when a slave crtc is active

Tobias Stoeckmann (1):
  render: Fix out of boundary heap access

git tag: xorg-server-1.19.3

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.3.tar.bz2
MD5:  015d2fc4b9f2bfe7a626edb63a62c65e  xorg-server-1.19.3.tar.bz2
SHA1: 77f580ffa22a8bbcc3536e74e19114e446417a9c  xorg-server-1.19.3.tar.bz2
SHA256: 677a8166e03474719238dfe396ce673c4234735464d6dadf2959b600d20e5a98  
xorg-server-1.19.3.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.3.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.3.tar.gz
MD5:  a7a51420874af84d90720b60de7936be  xorg-server-1.19.3.tar.gz
SHA1: 30009ac9da414389afc30b5d61576a793778b639  xorg-server-1.19.3.tar.gz
SHA256: 8f93b98f1ac9fbd87515bfe329a069b48bbec98e5329584ab5fbf759a0953b8d  
xorg-server-1.19.3.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.3.tar.gz.sig

- ajax
___
xorg-announce mailing list
xorg-announce@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-announce

[ANNOUNCE] xorg-server 1.19.3

[Adam Jackson]

A couple more minor fixes, most notably a revert of a page-flipping
change that regressed some drivers.

Adam Jackson (2):
  Revert "present: Allow flipping with PRIME slave outputs"
  xserver 1.19.3

Chris Wilson (2):
  Revert "prime: Sync shared pixmap from root window instead of screen 
pixmap"
  os: Fix iteration over busfaults

Dr.-Ing. Dieter Jurzitza (1):
  glamor: Fix missing declaration in dash vertex shader

Olivier Fourdan (2):
  xwayland: clear cursor frame callback
  xwayland: Monitor client states to destroy callbacks

Qiang Yu (1):
  present: disable page flip only when a slave crtc is active

Tobias Stoeckmann (1):
  render: Fix out of boundary heap access

git tag: xorg-server-1.19.3

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.3.tar.bz2
MD5:  015d2fc4b9f2bfe7a626edb63a62c65e  xorg-server-1.19.3.tar.bz2
SHA1: 77f580ffa22a8bbcc3536e74e19114e446417a9c  xorg-server-1.19.3.tar.bz2
SHA256: 677a8166e03474719238dfe396ce673c4234735464d6dadf2959b600d20e5a98  
xorg-server-1.19.3.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.3.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.3.tar.gz
MD5:  a7a51420874af84d90720b60de7936be  xorg-server-1.19.3.tar.gz
SHA1: 30009ac9da414389afc30b5d61576a793778b639  xorg-server-1.19.3.tar.gz
SHA256: 8f93b98f1ac9fbd87515bfe329a069b48bbec98e5329584ab5fbf759a0953b8d  
xorg-server-1.19.3.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.3.tar.gz.sig

- 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: xwayland pull request for 1.19 branch

[Adam Jackson]

On Mon, 2017-03-13 at 06:06 -0400, Olivier Fourdan wrote:
> Hi,
> 
> I have cherry-picked a couple of fixes for Xwayland for the 
> server-1.19-branch.
> 
> _Important_: I squashed two commits from upstream for 1.19, namely:
> 
>   64ca14b xwayland: make sure client is not gone in sync callback
>   937527f xwayland: Monitor client states to destroy callbacks
> 
> I used "cherry-pick -x" and kept the original commit from the the best fix in 
> the squash commit message, i.e. 937527f.
> 
> I hope this is OK (I reckon it makes sense for the stable branch to get the 
> right code in one go).

Not just okay, preferred. Merged, thanks:

To ssh://git.freedesktop.org/git/xorg/xserver
   db1326c..18fcb66  server-1.19-branch -> server-1.19-branch

- 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

Attach Touchscreen to X Screen

[Mike Werner]

Hi,

I need to run multiple touch screens on an OpenSuSE 13.2 system, as well as on 
an Ubuntu 16.04. Every thing works „fine“ when the system only has one graphics 
card (Nvidia) installed. Unfortunately the systems is required to provide two 
graphics cards. In this case the system has two XScreens and my approach 
mapping the xinput ID to a display port does not work any longer. It seems that 
xinput is only able to work properly with one xscreen (i.e. screen 0).

Is there a way to have multiple touch screens connected to multiple graphics 
cards? How can this be achieved?

Kind regrads

Mike
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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: `pkg-config --static --libs x11` unusable for static linking?

[walter harms]

you are aware the glibc does not support static linking ?

re,
 wh

Am 15.03.2017 02:16, schrieb x...@pengaru.com:
> Hello list,
> 
> I'm trying to support clean-ish static linking of a small autotools and
> libx11-using monitoring program via:
> 
> PKG_CONFIG="pkg-config --static" LDFLAGS="-static" ./configure
> 
> But linking fails on libdl and libpthread symbols:
> 
> $ gcc  -g -O2  -static -o vwm vwm-clickety.o vwm-composite.o vwm-context.o 
> vwm-desktop.o vwm-key.o vwm-launch.o vwm-logo.o vwm-overlays.o vwm-screen.o 
> vwm-vwm.o vwm-window.o vwm-xevent.o vwm-xserver.o vwm-xwindow.o -lXinerama 
> -lXrandr -lXext -lXcomposite -lXdamage -lXfixes -lXrender -lX11 -lpthread 
> -lxcb -lXau -lXdmcp  libvmon/libvmon.a 
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.a(xim_trans.o):
>  In function `_XimXTransSocketINETConnect':
> (.text+0xe32): warning: Using 'getaddrinfo' in statically linked applications 
> requires at runtime the shared libraries from the glibc version used for 
> linking
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.a(CrGlCur.o):
>  In function `open_library':
> (.text+0x32): undefined reference to `dlopen'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.a(CrGlCur.o):
>  In function `fetch_symbol':
> (.text+0x61): undefined reference to `dlsym'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libX11.a(CrGlCur.o):
>  In function `fetch_symbol':
> (.text+0x85): undefined reference to `dlsym'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
>  In function `xcb_disconnect.part.0':
> (.text+0x27): undefined reference to `pthread_mutex_destroy'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
>  In function `xcb_connect_to_fd':
> (.text+0x140): undefined reference to `pthread_mutex_init'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
>  In function `xcb_connect_to_fd':
> (.text+0x262): undefined reference to `pthread_mutex_lock'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
>  In function `xcb_connect_to_fd':
> (.text+0x27d): undefined reference to `pthread_mutex_unlock'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
>  In function `_xcb_conn_wait':
> (.text+0x472): undefined reference to `pthread_mutex_unlock'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
>  In function `_xcb_conn_wait':
> (.text+0x4ba): undefined reference to `pthread_mutex_lock'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
>  In function `_xcb_conn_wait':
> (.text+0x691): undefined reference to `pthread_mutex_lock'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_conn.o):
>  In function `_xcb_conn_wait':
> (.text+0x6e5): undefined reference to `pthread_cond_wait'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
>  In function `get_socket_back':
> (.text+0x41): undefined reference to `pthread_cond_wait'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
>  In function `get_socket_back':
> (.text+0x66): undefined reference to `pthread_mutex_unlock'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
>  In function `get_socket_back':
> (.text+0x7b): undefined reference to `pthread_mutex_lock'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
>  In function `get_socket_back':
> (.text+0x8d): undefined reference to `pthread_cond_broadcast'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
>  In function `xcb_prefetch_maximum_request_length.part.0':
> (.text+0xd4): undefined reference to `pthread_mutex_lock'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
>  In function `xcb_get_maximum_request_length':
> (.text+0x191): undefined reference to `pthread_mutex_lock'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
>  In function `xcb_get_maximum_request_length':
> (.text+0x1a2): undefined reference to `pthread_mutex_unlock'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
>  In function `_xcb_out_init':
> (.text+0x276): undefined reference to `pthread_mutex_init'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
>  In function `_xcb_out_destroy':
> (.text+0x295): undefined reference to `pthread_cond_destroy'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
>  In function `_xcb_out_send':
> (.text+0x315): undefined reference to `pthread_cond_broadcast'
> /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libxcb.a(xcb_out.o):
>  In function `xcb_writev':
> (.text+0x35c): undefined reference to `pthread_mutex_lock'
> 

Re: [PATCH xserver 2/2] glamor: Always purge the FBO cache in BlockHandler

[Max Staudt]

On 03/06/2017 07:02 PM, Eric Anholt wrote:
> For re-adding an FBO cache, I would need to see that we have
> APPLE_object_purgeable used so that the FBO cache can be evicted, [...]

When I checked a few months ago, only the i915 Mesa and kernel drivers
implemented this. Maybe we can enable the FBO cache *iff* the driver
supports this extension?


Max

___
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: Video tearing with modesetting driver and Intel Sandybridge graphics

[Tino Mettler]

On Wed, Mar 15, 2017 at 18:13:09 +0900, Michel Dänzer wrote:
> Same problem with fullscreen and windowed?

I can't really tell. The tearing happens in the upper part of the
screen. When moving the mpv window to the top of the screen, the
location where tearing happens in fullscreen mode is occupied by the
titlebar of the mpv window.

Regards,
Tino
___
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: Video tearing with modesetting driver and Intel Sandybridge graphics

[Michel Dänzer]

On 15/03/17 05:53 PM, Tino Mettler wrote:
> On Wed, Mar 15, 2017 at 10:34:48 +0900, Michel Dänzer wrote:
>> On 14/03/17 07:52 PM, Tino Mettler wrote:
>>> Hi,
>>>
>>> I get tearing video with the modesetting driver on a Debian Sid
>>> installation.
>>
>> Which desktop environment are you using?
> 
> I use Gnome3 (as cited below).
> 
>>
>>
>>> It happens at least in VLC and Firefox in Gnome3 using HDMI output of
>>> the Sandybridge graphics.
>>
>> In Firefox, you probably need to force hardware compositing by setting
>> layers.acceleration.force-enabled=true in about:config . Check what
>> about:support says for *_COMPOSITING.
> 
> I'll try that. Meanwhile, I also tried mpv with "--vo xv", "--vo
> opengl" and "--vo opengl --hwdec vaapi" and always got tearing video.

Same problem with fullscreen and windowed?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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: Video tearing with modesetting driver and Intel Sandybridge graphics

[Tino Mettler]

On Wed, Mar 15, 2017 at 10:34:48 +0900, Michel Dänzer wrote:
> On 14/03/17 07:52 PM, Tino Mettler wrote:
> > Hi,
> > 
> > I get tearing video with the modesetting driver on a Debian Sid
> > installation.
> 
> Which desktop environment are you using?

I use Gnome3 (as cited below).

> 
> 
> > It happens at least in VLC and Firefox in Gnome3 using HDMI output of
> > the Sandybridge graphics.
> 
> In Firefox, you probably need to force hardware compositing by setting
> layers.acceleration.force-enabled=true in about:config . Check what
> about:support says for *_COMPOSITING.

I'll try that. Meanwhile, I also tried mpv with "--vo xv", "--vo
opengl" and "--vo opengl --hwdec vaapi" and always got tearing video.

Regards,
Tino
___
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