Re: Hints for debugging a weird sw-cursor issue ?

2016-08-31 Thread Dave Airlie 
On 1 September 2016 at 11:28, Michel Dänzer  wrote:
> On 01/09/16 10:24 AM, Michel Dänzer wrote:
>> On 01/09/16 08:33 AM, Carsten Haitzler (The Rasterman) wrote:
>>> On Thu, 1 Sep 2016 06:36:32 +1000 Dave Airlie  said:
 On 31 August 2016 at 22:10, Hans de Goede  wrote:
> Hi All,
>
> I've noticed a weird sw-cursor issue when a slave-output is active
> (I believe this is a sw-cursor issue because show_cursor never
>  gets called when a slave-output is active at server start).
>
> I'm seeing this with both 1.18 and master and with both the
> intel and the modesetting drivers (running gnome3 / gnome-shell).
>
> Everything is fine until I start glxgears (*) then the cursor becomes
> invisible (flickering on the intel driver) when it is near the
> top of the screen. Basically there is a horizontal bar where
> the cursor does not show. Note this goes for the entire monitor,
> not just where glxgears is running. This bar is near the top of
> the screen, but not completely at the top, there is a small area
> near the top where the cursor still shows.
>
> Interestingly enough if I disable vblank for glxgears the problem
> remains, but the bar becomes smaller (less high).
>
> So anyone got any clues for debugging this ?

 Sounds like some wierdass tearing,

 since swcursor has to paint the cursor on the screen, so you might
 be seeing frames where the cursor hasn't been painted yet.
>>>
>>> that'd likely be it. remember that on an update of the screen, if the update
>>> draws where the cursor is, the cursor is "destroyed" then some time after 
>>> this
>>> it's repainted on top directly to the fb. thats how sw cursors have been 
>>> done
>>> in x as long as i can remember. when the cursor paints it also makes a copy 
>>> of
>>> the region it paints to to an offscreen buffer area so if the cursor itself
>>> moves/changes, it pastes that back on again to wipe the cursor, then does 
>>> the
>>> above "draw it to the fb" again.
>>>
>>> there's a good chance the cursor draw is being hooked to some vblank 
>>> interrupt
>>> and thus if cursor is close to the top the draw is not done yet when screen
>>> scans out... thus the bar at the top. i should assume your display is likely
>>> composited right? which means it may be that that area is being drawn
>>> regardless of where glxgears is. compositor is drawing it.
>>>
>>> good luck with this one. i have an idea that'd make it better but not 
>>> perfect.
>>> your solutions are not going to be pretty with various downsides but they 
>>> may
>>> fix the flickering/invisible thing. :)
>>
>> FWIW, one solution for this is TearFree.
>
> Also, obviously HW cursor support for GPU screens would avoid it in the
> first place.

There was a patch that mostly did this posted a while back, might be worth
picking up, however doesn't fix the USB devices which have no hw cursor,
though there was some kernel hacks posted to make the USB kernel driver
composit a cursor when sending data to the usb device.

Dave.
___
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: Hints for debugging a weird sw-cursor issue ?

2016-08-31 Thread Michel Dänzer 
On 01/09/16 10:24 AM, Michel Dänzer wrote:
> On 01/09/16 08:33 AM, Carsten Haitzler (The Rasterman) wrote:
>> On Thu, 1 Sep 2016 06:36:32 +1000 Dave Airlie  said:
>>> On 31 August 2016 at 22:10, Hans de Goede  wrote:
 Hi All,

 I've noticed a weird sw-cursor issue when a slave-output is active
 (I believe this is a sw-cursor issue because show_cursor never
  gets called when a slave-output is active at server start).

 I'm seeing this with both 1.18 and master and with both the
 intel and the modesetting drivers (running gnome3 / gnome-shell).

 Everything is fine until I start glxgears (*) then the cursor becomes
 invisible (flickering on the intel driver) when it is near the
 top of the screen. Basically there is a horizontal bar where
 the cursor does not show. Note this goes for the entire monitor,
 not just where glxgears is running. This bar is near the top of
 the screen, but not completely at the top, there is a small area
 near the top where the cursor still shows.

 Interestingly enough if I disable vblank for glxgears the problem
 remains, but the bar becomes smaller (less high).

 So anyone got any clues for debugging this ?
>>>
>>> Sounds like some wierdass tearing,
>>>
>>> since swcursor has to paint the cursor on the screen, so you might
>>> be seeing frames where the cursor hasn't been painted yet.
>>
>> that'd likely be it. remember that on an update of the screen, if the update
>> draws where the cursor is, the cursor is "destroyed" then some time after 
>> this
>> it's repainted on top directly to the fb. thats how sw cursors have been done
>> in x as long as i can remember. when the cursor paints it also makes a copy 
>> of
>> the region it paints to to an offscreen buffer area so if the cursor itself
>> moves/changes, it pastes that back on again to wipe the cursor, then does the
>> above "draw it to the fb" again.
>>
>> there's a good chance the cursor draw is being hooked to some vblank 
>> interrupt
>> and thus if cursor is close to the top the draw is not done yet when screen
>> scans out... thus the bar at the top. i should assume your display is likely
>> composited right? which means it may be that that area is being drawn
>> regardless of where glxgears is. compositor is drawing it.
>>
>> good luck with this one. i have an idea that'd make it better but not 
>> perfect.
>> your solutions are not going to be pretty with various downsides but they may
>> fix the flickering/invisible thing. :)
> 
> FWIW, one solution for this is TearFree.

Also, obviously HW cursor support for GPU screens would avoid it in the
first place.


-- 
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: Hints for debugging a weird sw-cursor issue ?

2016-08-31 Thread Michel Dänzer 
On 01/09/16 08:33 AM, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 1 Sep 2016 06:36:32 +1000 Dave Airlie  said:
>> On 31 August 2016 at 22:10, Hans de Goede  wrote:
>>> Hi All,
>>>
>>> I've noticed a weird sw-cursor issue when a slave-output is active
>>> (I believe this is a sw-cursor issue because show_cursor never
>>>  gets called when a slave-output is active at server start).
>>>
>>> I'm seeing this with both 1.18 and master and with both the
>>> intel and the modesetting drivers (running gnome3 / gnome-shell).
>>>
>>> Everything is fine until I start glxgears (*) then the cursor becomes
>>> invisible (flickering on the intel driver) when it is near the
>>> top of the screen. Basically there is a horizontal bar where
>>> the cursor does not show. Note this goes for the entire monitor,
>>> not just where glxgears is running. This bar is near the top of
>>> the screen, but not completely at the top, there is a small area
>>> near the top where the cursor still shows.
>>>
>>> Interestingly enough if I disable vblank for glxgears the problem
>>> remains, but the bar becomes smaller (less high).
>>>
>>> So anyone got any clues for debugging this ?
>>
>> Sounds like some wierdass tearing,
>>
>> since swcursor has to paint the cursor on the screen, so you might
>> be seeing frames where the cursor hasn't been painted yet.
> 
> that'd likely be it. remember that on an update of the screen, if the update
> draws where the cursor is, the cursor is "destroyed" then some time after this
> it's repainted on top directly to the fb. thats how sw cursors have been done
> in x as long as i can remember. when the cursor paints it also makes a copy of
> the region it paints to to an offscreen buffer area so if the cursor itself
> moves/changes, it pastes that back on again to wipe the cursor, then does the
> above "draw it to the fb" again.
> 
> there's a good chance the cursor draw is being hooked to some vblank interrupt
> and thus if cursor is close to the top the draw is not done yet when screen
> scans out... thus the bar at the top. i should assume your display is likely
> composited right? which means it may be that that area is being drawn
> regardless of where glxgears is. compositor is drawing it.
> 
> good luck with this one. i have an idea that'd make it better but not perfect.
> your solutions are not going to be pretty with various downsides but they may
> fix the flickering/invisible thing. :)

FWIW, one solution for this is TearFree.


-- 
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 v2 util-modular] build.sh: add libinput and xf86-input-libinput

2016-08-31 Thread Peter Hutterer 
Signed-off-by: Peter Hutterer 
---
Well, that'll teach me to send untested patches. Sorry.

Changes to v1:
- add libinput special handling to clone()
- confirmed it actually worked :)

 build.sh | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/build.sh b/build.sh
index 369afc8..01c396d 100755
--- a/build.sh
+++ b/build.sh
@@ -516,6 +516,9 @@ clone() {
 "libevdev")
 BASEDIR=""
 ;;
+"libinput")
+   BASEDIR="wayland/"
+   ;;
 *)
 BASEDIR="xorg/"
 ;;
@@ -1154,12 +1157,16 @@ build_all_modules() {
 build app xwud
 build xserver ""
 case $HOST_OS in
-   Linux) build libevdev "";;
+   Linux)
+   build libevdev ""
+   build libinput ""
+   ;;
 esac
 case $HOST_OS in
Linux)
build driver xf86-input-evdev
build driver xf86-input-joystick
+   build driver xf86-input-libinput
;;
FreeBSD | NetBSD | OpenBSD | Dragonfly | GNU/kFreeBSD)
build driver xf86-input-joystick
-- 
2.7.4

___
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#836214: Xorg: video acceleration regression for Radeon Xpress 200M (r300)

2016-08-31 Thread Dennis Mayr 
Package: xserver-xorg-video-ati
Version: 1:7.6 & 1:7.7

Good day Debian world,

I'm curious if you've observed  a performance regression in Xorg versions
above 1:7.5 (i.e. any version that can use DRI3) for integrated Radeon
chips using the r300 driver.

At least in Ubuntu, when using any version above 1:7.5.0-1, tearing ensues,
regardless of the presence of a xorg.conf config file to enable/disable
options to improve framerate. Enabling DRI3 only worsens the performance
regression, and accentuates tearing.

I've been advised to bisect Xorg versions to pinpoint the problematic
package version, but my machine is rather old (10 years) and I ran out of
disk space cloning the repos to do so. I retired from the IT industry, now
turned into a guitar builder, so I haven't really upgraded anything else
besides hand tools, but if there's a problem in linux, I feel the need to
report it.

In case you've encountered such a problem, I've filed reports both in
lauchpad and upstream for anyone to read.

If this regression isn't present in Debian, please disregard this message.

Reports:
-Launchpad:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1610591
-Upstream: https://bugs.freedesktop.org/show_bug.cgi?id=97228

Cheers
-- 
dennis mayr
|mobile > +56 [9] 5867 8727
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[PATCH xserver] test: Run some XTS5 integration tests against Xvfb if possible.

2016-08-31 Thread Eric Anholt 
By default the tests will be skipped.  However, if you set XTEST_DIR
to the repo of a built X Test Suite and PIGLIT_DIR to a piglit repo
(no build necessary), make check will run piglit's xts-render tests
against Xvfb.

We could run more of XTS5, but I haven't spent the time identifying
what additional subset would be worth running, since much of it is
only really testing the client libraries.  We want to make sure that
we keep the runtime down, and this subset of the test suite took 92
seconds according to piglit.
---

Note that this requires the xts5 and piglit series that I've just sent
out.  Next step is to test glamor in a similar way.

 test/Makefile.am | 25 --
 test/scripts/xinit-piglit-session.sh | 47 +
 test/scripts/xvfb-piglit.sh  | 66 
 3 files changed, 135 insertions(+), 3 deletions(-)
 create mode 100755 test/scripts/xinit-piglit-session.sh
 create mode 100755 test/scripts/xvfb-piglit.sh

diff --git a/test/Makefile.am b/test/Makefile.am
index f5e54680b005..5a35e2bb198f 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -12,8 +12,23 @@ endif
 endif
 check_LTLIBRARIES = libxservertest.la
 
-TESTS=$(noinst_PROGRAMS)
-TESTS_ENVIRONMENT = $(XORG_MALLOC_DEBUG_ENV)
+if XVFB
+XVFB_TESTS = scripts/xvfb-piglit.sh
+endif
+
+SCRIPT_TESTS = \
+   $(XVFB_TESTS) \
+   $(NULL)
+
+TESTS = \
+   $(noinst_PROGRAMS) \
+   $(SCRIPT_TESTS) \
+   $(NULL)
+
+TESTS_ENVIRONMENT = \
+   XSERVER_DIR=$(abs_top_builddir) \
+   $(XORG_MALLOC_DEBUG_ENV) \
+   $(NULL)
 
 AM_CFLAGS = $(DIX_CFLAGS) @XORG_CFLAGS@
 AM_CPPFLAGS = $(XORG_INCS)
@@ -139,5 +154,9 @@ endif
 libxservertest_la_DEPENDENCIES = $(libxservertest_la_LIBADD)
 endif
 
-EXTRA_DIST = ddxstubs.c
+EXTRA_DIST = \
+   $(SCRIPT_TESTS) \
+   scripts/xinit-piglit-session.sh \
+   ddxstubs.c \
+   $(NULL)
 
diff --git a/test/scripts/xinit-piglit-session.sh 
b/test/scripts/xinit-piglit-session.sh
new file mode 100755
index ..0f0c7943d34e
--- /dev/null
+++ b/test/scripts/xinit-piglit-session.sh
@@ -0,0 +1,47 @@
+#!/bin/sh
+
+# .xinitrc replacement to run piglit and exit.
+#
+# Note that piglit will run many processes against the server, so
+# running the server with -noreset is recommended to improve runtime.
+
+set -e
+
+if test "x$PIGLIT_DIR" = "x"; then
+echo "PIGLIT_DIR must be set to the directory of the piglit repository."
+exit 1
+fi
+
+if test "x$PIGLIT_RESULTS_DIR" = "x"; then
+echo "PIGLIT_RESULTS_DIR must be defined"
+exit 1
+fi
+
+if test "x$XTEST_DIR" = "x"; then
+echo "XTEST_DIR must be set to the root of the built xtest tree."
+exit 1
+fi
+
+cd $PIGLIT_DIR
+
+# Write the piglit.conf we'll use for our testing.  Don't use the
+# default piglit.conf name because that may overwrite a local
+# piglit.conf.
+PIGLITCONF=piglit-xserver-test.conf
+cat < $PIGLITCONF
+[xts]
+path=$XTEST_DIR
+EOF
+
+# Skip some tests that are failing at the time of importing the script.
+#"REPORT: min_bounds, rbearing was 0, expecting 2"
+PIGLIT_ARGS="$PIGLIT_ARGS -x xlistfontswithinfo@3"
+PIGLIT_ARGS="$PIGLIT_ARGS -x xlistfontswithinfo@4"
+PIGLIT_ARGS="$PIGLIT_ARGS -x xloadqueryfont@1"
+PIGLIT_ARGS="$PIGLIT_ARGS -x xqueryfont@1"
+PIGLIT_ARGS="$PIGLIT_ARGS -x xqueryfont@2"
+#"REPORT: Incorrect pixel on inside of area at point (0, 0): 0x0 != 0x1"
+PIGLIT_ARGS="$PIGLIT_ARGS -x xgetimage@7"
+PIGLIT_ARGS="$PIGLIT_ARGS -x xgetsubimage@7"
+
+exec ./piglit-run.py xts-render -f $PIGLITCONF $PIGLIT_ARGS $PIGLIT_RESULTS_DIR
diff --git a/test/scripts/xvfb-piglit.sh b/test/scripts/xvfb-piglit.sh
new file mode 100755
index ..2a4e9405268d
--- /dev/null
+++ b/test/scripts/xvfb-piglit.sh
@@ -0,0 +1,66 @@
+#!/bin/sh
+
+set -e
+
+if test "x$XTEST_DIR" = "x"; then
+echo "XTEST_DIR must be set to the directory of the xtest repository."
+# Exit as a "skip" so make check works even without piglit.
+exit 77
+fi
+
+if test "x$PIGLIT_DIR" = "x"; then
+echo "PIGLIT_DIR must be set to the directory of the piglit repository."
+# Exit as a "skip" so make check works even without piglit.
+exit 77
+fi
+
+if test "x$XSERVER_DIR" = "x"; then
+echo "XSERVER_DIR must be set to the directory of the xserver repository."
+# Exit as a real failure because it should always be set.
+exit 1
+fi
+
+export PIGLIT_RESULTS_DIR=$PIGLIT_DIR/results/xvfb
+
+startx \
+$XSERVER_DIR/test/scripts/xinit-piglit-session.sh \
+-- \
+$XSERVER_DIR/hw/vfb/Xvfb \
+-noreset \
+-screen scrn 1280x1024x24
+
+# Write out piglit-summaries.
+SHORT_SUMMARY=$PIGLIT_RESULTS_DIR/summary
+LONG_SUMMARY=$PIGLIT_RESULTS_DIR/long-summary
+$PIGLIT_DIR/piglit-summary.py -s $PIGLIT_RESULTS_DIR > $SHORT_SUMMARY
+$PIGLIT_DIR/piglit-summary.py $PIGLIT_RESULTS_DIR > $LONG_SUMMARY
+
+# Write the short summary to make check's log file.
+cat $SHORT_SUMMARY
+
+# Parse the piglit summary to decide on our

[PATCH xts 2/3] editorconfig: Set up some default indentation settings for the project.

2016-08-31 Thread Eric Anholt 
Emacs was indenting badly in the previous change without it.
---
 .editorconfig | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 .editorconfig

diff --git a/.editorconfig b/.editorconfig
new file mode 100644
index ..5fa2d6311abd
--- /dev/null
+++ b/.editorconfig
@@ -0,0 +1,12 @@
+# To use this config on you editor, follow the instructions at:
+# http://editorconfig.org
+
+root = true
+
+[*]
+charset = utf-8
+insert_final_newline = true
+
+[*.{c,h,cpp,hpp,cc,hh}]
+indent_style = tab
+indent_size = 8
-- 
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

[PATCH xts 3/3] autogen: Set the default patch prefix.

2016-08-31 Thread Eric Anholt 
---
 autogen.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/autogen.sh b/autogen.sh
index fc34bd55c443..ee30ef4aa858 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -9,6 +9,9 @@ cd $srcdir
 autoreconf -v --install || exit 1
 cd $ORIGDIR || exit $?
 
+git config --local --get format.subjectPrefix ||
+git config --local format.subjectPrefix "PATCH xts"
+
 if test -z "$NOCONFIGURE"; then
 $srcdir/configure "$@"
 fi
-- 
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

[PATCH xts 1/3] Default to using the tetexec.cfg from the build directory.

2016-08-31 Thread Eric Anholt 
One less environment variable the user needs to set to prevent
spurious failures.
---
 src/tet3/apilib/Makefile.am | 3 ++-
 src/tet3/apilib/dconfig.c   | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/tet3/apilib/Makefile.am b/src/tet3/apilib/Makefile.am
index 70391ed910df..e55afb3e6617 100644
--- a/src/tet3/apilib/Makefile.am
+++ b/src/tet3/apilib/Makefile.am
@@ -1,4 +1,5 @@
-AM_CPPFLAGS = -I$(srcdir)/../inc -I$(top_srcdir)/include
+AM_CPPFLAGS = -I$(srcdir)/../inc -I$(top_srcdir)/include \
+   -DTET_DEFAULT_CONFIG=\"$(abs_top_builddir)/tetexec.cfg\"
 
 # libapi_s is the shared portion of the library
 xtslibdir = $(libexecdir)/xts5
diff --git a/src/tet3/apilib/dconfig.c b/src/tet3/apilib/dconfig.c
index 129557909dd1..acad188e 100644
--- a/src/tet3/apilib/dconfig.c
+++ b/src/tet3/apilib/dconfig.c
@@ -144,7 +144,7 @@ TET_IMPORT void tet_config()
/* determine the config file name from the environment */
file = getenv("TET_CONFIG");
if (file == NULL || *file == '\0')
-   return;
+   file = TET_DEFAULT_CONFIG;
 
/* open the file */
if ((fp = fopen(file, "r")) == (FILE *) 0) {
-- 
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: Hints for debugging a weird sw-cursor issue ?

2016-08-31 Thread The Rasterman 
On Thu, 1 Sep 2016 06:36:32 +1000 Dave Airlie  said:

> On 31 August 2016 at 22:10, Hans de Goede  wrote:
> > Hi All,
> >
> > I've noticed a weird sw-cursor issue when a slave-output is active
> > (I believe this is a sw-cursor issue because show_cursor never
> >  gets called when a slave-output is active at server start).
> >
> > I'm seeing this with both 1.18 and master and with both the
> > intel and the modesetting drivers (running gnome3 / gnome-shell).
> >
> > Everything is fine until I start glxgears (*) then the cursor becomes
> > invisible (flickering on the intel driver) when it is near the
> > top of the screen. Basically there is a horizontal bar where
> > the cursor does not show. Note this goes for the entire monitor,
> > not just where glxgears is running. This bar is near the top of
> > the screen, but not completely at the top, there is a small area
> > near the top where the cursor still shows.
> >
> > Interestingly enough if I disable vblank for glxgears the problem
> > remains, but the bar becomes smaller (less high).
> >
> > So anyone got any clues for debugging this ?
> 
> Sounds like some wierdass tearing,
> 
> since swcursor has to paint the cursor on the screen, so you might
> be seeing frames where the cursor hasn't been painted yet.

that'd likely be it. remember that on an update of the screen, if the update
draws where the cursor is, the cursor is "destroyed" then some time after this
it's repainted on top directly to the fb. thats how sw cursors have been done
in x as long as i can remember. when the cursor paints it also makes a copy of
the region it paints to to an offscreen buffer area so if the cursor itself
moves/changes, it pastes that back on again to wipe the cursor, then does the
above "draw it to the fb" again.

there's a good chance the cursor draw is being hooked to some vblank interrupt
and thus if cursor is close to the top the draw is not done yet when screen
scans out... thus the bar at the top. i should assume your display is likely
composited right? which means it may be that that area is being drawn
regardless of where glxgears is. compositor is drawing it.

good luck with this one. i have an idea that'd make it better but not perfect.
your solutions are not going to be pretty with various downsides but they may
fix the flickering/invisible thing. :)

> Dave.
> ___
> 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

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
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: Hints for debugging a weird sw-cursor issue ?

2016-08-31 Thread Dave Airlie 
On 31 August 2016 at 22:10, Hans de Goede  wrote:
> Hi All,
>
> I've noticed a weird sw-cursor issue when a slave-output is active
> (I believe this is a sw-cursor issue because show_cursor never
>  gets called when a slave-output is active at server start).
>
> I'm seeing this with both 1.18 and master and with both the
> intel and the modesetting drivers (running gnome3 / gnome-shell).
>
> Everything is fine until I start glxgears (*) then the cursor becomes
> invisible (flickering on the intel driver) when it is near the
> top of the screen. Basically there is a horizontal bar where
> the cursor does not show. Note this goes for the entire monitor,
> not just where glxgears is running. This bar is near the top of
> the screen, but not completely at the top, there is a small area
> near the top where the cursor still shows.
>
> Interestingly enough if I disable vblank for glxgears the problem
> remains, but the bar becomes smaller (less high).
>
> So anyone got any clues for debugging this ?

Sounds like some wierdass tearing,

since swcursor has to paint the cursor on the screen, so you might
be seeing frames where the cursor hasn't been painted yet.

Dave.
___
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

[ANNOUNCE] libXfont 1.5.2

2016-08-31 Thread Adam Jackson 
Maintenance branch release, primarily for bdftopcf's benefit as it's
the only thing that really needs the Xfont1 API. (xfs uses it too, I
believe, but could be ported to Xfont2). If someone wanted to step up
and merge Xfont1 into bdtopcf directly, that'd be great.

Adam Jackson (1):
  libXfont 1.5.2

Alan Coopersmith (1):
  doc: add a couple olinks to fsproto & xfs-design docs

Benjamin Tissoires (1):
  bdfReadCharacters: Allow negative DWIDTH values

Jeremy Huddleston Sequoia (6):
  stubs: Add missing externs for declarations in the NO_WEAK_SYMBOLS && PIC 
stubs resolution
  Use NO_WEAK_SYMBOLS instead of -flat_namespace
  FreeType: Correct an allocation size
  bitmap: Bail out on invalid input to FontFileMakeDir instead of calling 
calloc for 0 bytes
  fserve: Silence a -Wformat warning
  fserve: Fix a buffer read overrun in _fs_client_access

Keith Packard (1):
  Fix warnings

Thomas Klausner (1):
  Fix is*() usage.

git tag: libXfont-1.5.2

http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.2.tar.bz2
MD5:  254ee42bd178d18ebc7a73aacfde7f79  libXfont-1.5.2.tar.bz2
SHA1: a9470774f271622c1b425826d1c8836ed96e4a96  libXfont-1.5.2.tar.bz2
SHA256: 02945ea68da447102f3e6c2b896c1d2061fd115de99404facc2aca3ad7010d71  
libXfont-1.5.2.tar.bz2
PGP:  
http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.2.tar.bz2.sig

http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.2.tar.gz
MD5:  e8c616db0e59df4614980915e79bb05e  libXfont-1.5.2.tar.gz
SHA1: 71fd30da5d2dd7a93c363262f66c7a4217a120a8  libXfont-1.5.2.tar.gz
SHA256: a7350c75171d03d06ae0d623e42240356d6d3e1ac7dfe606639bf20f0d653c93  
libXfont-1.5.2.tar.gz
PGP:  
http://xorg.freedesktop.org/archive/individual/lib/libXfont-1.5.2.tar.gz.sig

- ajax

signature.asc
Description: This is a digitally signed message part
___
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] modesetting: Do not use function local static variables

2016-08-31 Thread Keith Packard 
Hans de Goede  writes:

> The modesetting driver may be driving 2 screens (slave and master
> gpu), which may have different behavior wrt hardware cursor support.
>
> So stop using static variables and instead store the hw-cursor support
> related data in a per screen struct. While at it actually make it per
> crtc data as in theory different crtc's could have different hw-cursor
> support.
>
> Signed-off-by: Hans de Goede 

The things you find if you look long enough...

Reviewed-by: Keith Packard 
-- 
-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: [PATCH xserver] randr: Do not check the screen size bound for gpu screens

2016-08-31 Thread Nikhil Mahale 
> 
> OTOH this may indeed be a server bug, but your fix is not the right
> one, I wonder why we are doing a RRSetScreenSize for slave GPU-s at
> all. Since we already check that the Screen is big enough in
> ProcRRSetCrtcConfig?

We are looking for answer of this question, may be Dave or Ajax knows
about this.

Thanks,
Nikhil Mahale

On 08/31/2016 01:40 PM, Timo Aaltonen wrote:
> 
> Any update on this?
> 
> On 20.06.2016 20:27, Hans de Goede wrote:
>> Hi,
>>
>> On 20-06-16 18:32, Nikhil Mahale wrote:
>>> Sorry for late reply, Hans. See inline -
>>>
>>> On 06/13/2016 10:36 PM, Hans de Goede wrote:
 Hi,

 On 20-05-16 07:00, Nikhil Mahale wrote:
> For gpu screen, CrtcSet set/adjust the master screen size along
> mode in following callstack -
>
>   ProcRRSetCrtcConfig()
> |
> -> RRCrtcSet()
> |
> -> rrCheckPixmapBounding()
> |
> -> pScrPriv->rrScreenSetSize()
>
> Checking screen size bound for gpus screen cause some configurations
> to fails, e.g
>
>   $ xrandr --output eDP --mode 1920x1080 --pos 0x0 --output HDMI \
>   --mode 2560x1440 --pos 0x0
>
>   Here xrandr utility first sets screen size to 2560x1440 which
>   gets resized to 1920x1080 on RRSetCrtcConfig request for eDP,
>   and then RRSetCrtcConfig request for HDMI fails because
>   of failure of screen bound check.

 Hmm, but one has the same problem when not using clone mode,
 then the master screen size must be made big enough to hold
 both crtc-s, so how come this has never been a problem then ?

 I've a feeling that in that case we end up doing things in
 finer grained steps. What if you do:

 $ xrandr --output eDP --mode 1920x1080 --pos 0x0
 $ xrandr --output HDMI --mode 2560x1440 --pos 0x0

 ? Does that work ?  If that works, which I would expect it will,
 then this should be fixed in the xrandr utility instead IMHO.

 Just circumventing the screen size check for slave outputs
 seem to go against the xrandr-1.2 spec to me.

 Also I guess one can reproduce the same problem without using
 slave-outputs, in which case your patch will not help.

>>>
>>> I don't think we could reproduce this problem without using slave-
>>> output, because rrScreenSetSize() path which I explained in commit
>>> message is not there, isn't it?
>>>
>>> Let me try to explain differece between both sequence of commands,
>>> please correct me if required -
>>>
>>> $ xrandr --output eDP --mode 1920x1080 --pos 0x0 --output HDMI \
>>> --mode 2560x1440 --pos 0x0
>>>
>>> ---
>>> | Cmd | Screen size  |  eDP  | HDMI   |
>>> ---
>>> | RRSetScreenSize | 2560x1440| - |   -|
>>> ---
>>> | RRSetCrtcConfig | 1920x1080| 1920x1080 |   -|
>>> | | changed from 2560x1440   |   ||
>>> | | because of rrScreenSetSize() |   ||
>>> | | path explained in commit |   ||
>>> | | msg. (A) |   ||
>>> ---
>>> | RRSetCrtcConfig | 2560x1440| 1920x1080 | failed |
>>> ---
>>
>> Ah I see now, this will only happen when the eDP is a slave output,
>> I was thinking that the HDMI would be a slave output, but that does
>> not matter, this problem will happen independ of the HDMI being a normal
>> or a slave output, as long as the eDP is a slave output.
>>
>>> $ xrandr --output eDP --mode 1920x1080 --pos 0x0
>>> $ xrandr --output HDMI --mode 2560x1440 --pos 0x0
>>>
>>>
>>> 
>>> | Cmd | Screen size|  eDP  | HDMI  |
>>> 
>>> | RRSetScreenSize | 1920x1080  | - |   -   |
>>> 
>>> | RRSetCrtcConfig | 1920x1080  | 1920x1080 |   -   |
>>> 
>>> | RRSetScreenSize | 2560x1440  | 1920x1080 |   -   |
>>> 
>>> | RRSetCrtcConfig | 2560x1440  | 1920x1080 | 2560x1440 |
>>> 
>>>
>>> Case (A) is not there in second sequence of xrand commands, so you
>>> could not reproduce

Re: [PATCH xserver] Add SyncSharedPixmap ScreenRec hook

2016-08-31 Thread Alex Deucher 
On Wed, Aug 31, 2016 at 4:56 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> Signed-off-by: Michel Dänzer 

Reviewed-by: Alex Deucher 

> ---
>  include/scrnintstr.h | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/include/scrnintstr.h b/include/scrnintstr.h
> index 5330714..52e8382 100644
> --- a/include/scrnintstr.h
> +++ b/include/scrnintstr.h
> @@ -347,6 +347,24 @@ typedef Bool (*SharePixmapBackingProcPtr)(PixmapPtr, 
> ScreenPtr, void **);
>
>  typedef Bool (*SetSharedPixmapBackingProcPtr)(PixmapPtr, void *);
>
> +#define HAS_SYNC_SHARED_PIXMAP 1
> +/* The SyncSharedPixmap hook has two purposes:
> + *
> + * 1. If the master driver has it, the slave driver can use it to
> + * synchronize the shared pixmap contents with the screen pixmap.
> + * 2. If the slave driver has it, the master driver can expect the slave
> + * driver to call the master screen's SyncSharedPixmap hook, so the master
> + * driver doesn't have to synchronize the shared pixmap contents itself,
> + * e.g. from the BlockHandler.
> + *
> + * A driver must only set the hook if it handles both cases correctly.
> + *
> + * The argument is the slave screen's pixmap_dirty_list entry, the hook is
> + * responsible for finding the corresponding entry in the master screen's
> + * pixmap_dirty_list.
> + */
> +typedef void (*SyncSharedPixmapProcPtr)(PixmapDirtyUpdatePtr);
> +
>  typedef Bool (*StartPixmapTrackingProcPtr)(PixmapPtr, PixmapPtr,
> int x, int y,
> int dst_x, int dst_y,
> @@ -616,6 +634,7 @@ typedef struct _Screen {
>
>  StartPixmapTrackingProcPtr StartPixmapTracking;
>  StopPixmapTrackingProcPtr StopPixmapTracking;
> +SyncSharedPixmapProcPtr SyncSharedPixmap;
>
>  SharedPixmapNotifyDamageProcPtr SharedPixmapNotifyDamage;
>  RequestSharedPixmapNotifyDamageProcPtr RequestSharedPixmapNotifyDamage;
> --
> 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
___
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 97228] Video acceleration *regression* for Radeon Xpress 200M (r300) in xorg-lts-xenial & xorg-lts-wily

2016-08-31 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=97228

--- Comment #12 from Dennis Mayr  ---
I was finally trying to bisect, but this machine has run out of drive space
while compiling the drivers (old machine, tight budget), and there's not enough
time off-production to keep trying in an efficient way, so I'll have to ask
someone else to help me out building the packages.

-- 
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] modesetting: Do not use function local static variables

2016-08-31 Thread Hans de Goede 
The modesetting driver may be driving 2 screens (slave and master
gpu), which may have different behavior wrt hardware cursor support.

So stop using static variables and instead store the hw-cursor support
related data in a per screen struct. While at it actually make it per
crtc data as in theory different crtc's could have different hw-cursor
support.

Signed-off-by: Hans de Goede 
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 10 --
 hw/xfree86/drivers/modesetting/drmmode_display.h |  2 ++
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 429c0fd..7ab6d4f 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -756,10 +756,9 @@ drmmode_set_cursor(xf86CrtcPtr crtc)
 drmmode_ptr drmmode = drmmode_crtc->drmmode;
 uint32_t handle = drmmode_crtc->cursor_bo->handle;
 modesettingPtr ms = modesettingPTR(crtc->scrn);
-static Bool use_set_cursor2 = TRUE;
 int ret;
 
-if (use_set_cursor2) {
+if (!drmmode_crtc->set_cursor2_failed) {
 CursorPtr cursor = xf86CurrentCursor(crtc->scrn->pScreen);
 
 ret =
@@ -769,7 +768,7 @@ drmmode_set_cursor(xf86CrtcPtr crtc)
 if (!ret)
 return TRUE;
 
-use_set_cursor2 = FALSE;
+drmmode_crtc->set_cursor2_failed = TRUE;
 }
 
 ret = drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, 
handle,
@@ -803,7 +802,6 @@ drmmode_load_cursor_argb_check(xf86CrtcPtr crtc, CARD32 
*image)
 drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
 int i;
 uint32_t *ptr;
-static Bool first_time = TRUE;
 
 /* cursor should be mapped already */
 ptr = (uint32_t *) (drmmode_crtc->cursor_bo->ptr);
@@ -811,11 +809,11 @@ drmmode_load_cursor_argb_check(xf86CrtcPtr crtc, CARD32 
*image)
 for (i = 0; i < ms->cursor_width * ms->cursor_height; i++)
 ptr[i] = image[i];  // cpu_to_le32(image[i]);
 
-if (drmmode_crtc->cursor_up || first_time) {
+if (drmmode_crtc->cursor_up || !drmmode_crtc->first_cursor_load_done) {
 Bool ret = drmmode_set_cursor(crtc);
 if (!drmmode_crtc->cursor_up)
 drmmode_hide_cursor(crtc);
-first_time = FALSE;
+drmmode_crtc->first_cursor_load_done = TRUE;
 return ret;
 }
 return TRUE;
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h 
b/hw/xfree86/drivers/modesetting/drmmode_display.h
index f774250..50976b8 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.h
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
@@ -92,6 +92,8 @@ typedef struct {
 int dpms_mode;
 struct dumb_bo *cursor_bo;
 Bool cursor_up;
+Bool set_cursor2_failed;
+Bool first_cursor_load_done;
 uint16_t lut_r[256], lut_g[256], lut_b[256];
 
 drmmode_bo rotate_bo;
-- 
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

[PATCH v2 xserver] modesetting: Hide cursor when initializing crtc

2016-08-31 Thread Hans de Goede 
When Xorg gets started directly from a wayland-gdm the crtc still has the
wayland hw cursor set. Combine this with Xorg immediately falling back to
a sw cursor because a slave-output has a monitor attached at startup; and
we end up with the wayland hardware cursor overlay fixed in its last
position + the Xorg sw cursor resulting in 2 cursors.

This commit fixes this by hiding any left-over cursors when initializing
the crtc.

Signed-off-by: Hans de Goede 
Reviewed-by: Eric Engestrom 
---
Changes in v2:
-Fix spelling error in comment
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index e9fce81..429c0fd 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -1147,6 +1147,9 @@ drmmode_crtc_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, 
drmModeResPtr mode_res
 drmmode_crtc->vblank_pipe = drmmode_crtc_vblank_pipe(num);
 crtc->driver_private = drmmode_crtc;
 
+/* Hide any cursors which may be active from previous users */
+drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, 0, 0, 0);
+
 /* Mark num'th crtc as in use on this device. */
 ms_ent->assigned_crtcs |= (1 << num);
 xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO, MS_LOGLEVEL_DEBUG,
-- 
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: [PATCH xserver] modesetting: Hide cursor when initializing crtc

2016-08-31 Thread Eric Engestrom 
On Wed, Aug 31, 2016 at 01:55:14PM +0200, Hans de Goede wrote:
> When Xorg gets started directly from a wayland-gdm the crtc still has the
> wayland hw cursor set. Combine this with Xorg immediately falling back to
> a sw cursor because a slave-output has a monitor attached at startup; and
> we end up with the wayland hardware cursor overlay fixed in its last
> position + the Xorg sw cursor resulting in 2 cursors.
> 
> This commit fixes this by hiding any left-over cursors when initializing
> the crtc.
> 
> Signed-off-by: Hans de Goede 
> ---
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index e9fce81..645d54c 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -1147,6 +1147,9 @@ drmmode_crtc_init(ScrnInfoPtr pScrn, drmmode_ptr 
> drmmode, drmModeResPtr mode_res
>  drmmode_crtc->vblank_pipe = drmmode_crtc_vblank_pipe(num);
>  crtc->driver_private = drmmode_crtc;
>  
> +/* Hide any cursors which me be active from previous users */

s/me/may/ :)

This looks reasonable:
Reviewed-by: Eric Engestrom 

> +drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, 0, 0, 0);
> +
>  /* Mark num'th crtc as in use on this device. */
>  ms_ent->assigned_crtcs |= (1 << num);
>  xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO, MS_LOGLEVEL_DEBUG,
> -- 
> 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

Hints for debugging a weird sw-cursor issue ?

2016-08-31 Thread Hans de Goede 

Hi All,

I've noticed a weird sw-cursor issue when a slave-output is active
(I believe this is a sw-cursor issue because show_cursor never
 gets called when a slave-output is active at server start).

I'm seeing this with both 1.18 and master and with both the
intel and the modesetting drivers (running gnome3 / gnome-shell).

Everything is fine until I start glxgears (*) then the cursor becomes
invisible (flickering on the intel driver) when it is near the
top of the screen. Basically there is a horizontal bar where
the cursor does not show. Note this goes for the entire monitor,
not just where glxgears is running. This bar is near the top of
the screen, but not completely at the top, there is a small area
near the top where the cursor still shows.

Interestingly enough if I disable vblank for glxgears the problem
remains, but the bar becomes smaller (less high).

So anyone got any clues for debugging this ?

Regards,

Hans


*) It does not matter how I start it, with DRI2 or DRI3, with
DRI_PRIME=1 or without
___
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] modesetting: Hide cursor when initializing crtc

2016-08-31 Thread Hans de Goede 
When Xorg gets started directly from a wayland-gdm the crtc still has the
wayland hw cursor set. Combine this with Xorg immediately falling back to
a sw cursor because a slave-output has a monitor attached at startup; and
we end up with the wayland hardware cursor overlay fixed in its last
position + the Xorg sw cursor resulting in 2 cursors.

This commit fixes this by hiding any left-over cursors when initializing
the crtc.

Signed-off-by: Hans de Goede 
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index e9fce81..645d54c 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -1147,6 +1147,9 @@ drmmode_crtc_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, 
drmModeResPtr mode_res
 drmmode_crtc->vblank_pipe = drmmode_crtc_vblank_pipe(num);
 crtc->driver_private = drmmode_crtc;
 
+/* Hide any cursors which me be active from previous users */
+drmModeSetCursor(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, 0, 0, 0);
+
 /* Mark num'th crtc as in use on this device. */
 ms_ent->assigned_crtcs |= (1 << num);
 xf86DrvMsgVerb(pScrn->scrnIndex, X_INFO, MS_LOGLEVEL_DEBUG,
-- 
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: [PATCH util-modular] build.sh: add libinput and xf86-input-libinput

2016-08-31 Thread Eric Engestrom 
On Wed, Aug 31, 2016 at 10:16:34AM +1000, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer 
> ---
>  build.sh | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/build.sh b/build.sh
> index 369afc8..3006ebc 100755
> --- a/build.sh
> +++ b/build.sh
> @@ -1155,11 +1155,13 @@ build_all_modules() {
>  build xserver ""
>  case $HOST_OS in
>   Linux) build libevdev "";;
> + Linux) build wayland libinput "";;

I don't think that's going to work. You should remove the break (;;) from
the previous line and simply add the `build` instruction on the next.

Cheers,
  Eric

>  esac
>  case $HOST_OS in
>   Linux)
>   build driver xf86-input-evdev
>   build driver xf86-input-joystick
> + build driver xf86-input-libinput
>   ;;
>   FreeBSD | NetBSD | OpenBSD | Dragonfly | GNU/kFreeBSD)
>   build driver xf86-input-joystick
> -- 
> 2.7.4
___
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] Add SyncSharedPixmap ScreenRec hook

2016-08-31 Thread Michel Dänzer 
On 31/08/16 05:56 PM, Michel Dänzer wrote:
> From: Michel Dänzer 
> 
> Signed-off-by: Michel Dänzer 
> ---
>  include/scrnintstr.h | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/include/scrnintstr.h b/include/scrnintstr.h
> index 5330714..52e8382 100644
> --- a/include/scrnintstr.h
> +++ b/include/scrnintstr.h
> @@ -347,6 +347,24 @@ typedef Bool (*SharePixmapBackingProcPtr)(PixmapPtr, 
> ScreenPtr, void **);
>  
>  typedef Bool (*SetSharedPixmapBackingProcPtr)(PixmapPtr, void *);
>  
> +#define HAS_SYNC_SHARED_PIXMAP 1
> +/* The SyncSharedPixmap hook has two purposes:
> + *
> + * 1. If the master driver has it, the slave driver can use it to
> + * synchronize the shared pixmap contents with the screen pixmap.
> + * 2. If the slave driver has it, the master driver can expect the slave
> + * driver to call the master screen's SyncSharedPixmap hook, so the master
> + * driver doesn't have to synchronize the shared pixmap contents itself,
> + * e.g. from the BlockHandler.
> + *
> + * A driver must only set the hook if it handles both cases correctly.
> + *
> + * The argument is the slave screen's pixmap_dirty_list entry, the hook is
> + * responsible for finding the corresponding entry in the master screen's
> + * pixmap_dirty_list.
> + */
> +typedef void (*SyncSharedPixmapProcPtr)(PixmapDirtyUpdatePtr);
> +
>  typedef Bool (*StartPixmapTrackingProcPtr)(PixmapPtr, PixmapPtr,
> int x, int y,
> int dst_x, int dst_y,
> @@ -616,6 +634,7 @@ typedef struct _Screen {
>  
>  StartPixmapTrackingProcPtr StartPixmapTracking;
>  StopPixmapTrackingProcPtr StopPixmapTracking;
> +SyncSharedPixmapProcPtr SyncSharedPixmap;
>  
>  SharedPixmapNotifyDamageProcPtr SharedPixmapNotifyDamage;
>  RequestSharedPixmapNotifyDamageProcPtr RequestSharedPixmapNotifyDamage;
> 

Here's an example how this hook can be used:

https://patchwork.freedesktop.org/patch/108074/


-- 
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] Add SyncSharedPixmap ScreenRec hook

2016-08-31 Thread Michel Dänzer 
From: Michel Dänzer 

Signed-off-by: Michel Dänzer 
---
 include/scrnintstr.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/scrnintstr.h b/include/scrnintstr.h
index 5330714..52e8382 100644
--- a/include/scrnintstr.h
+++ b/include/scrnintstr.h
@@ -347,6 +347,24 @@ typedef Bool (*SharePixmapBackingProcPtr)(PixmapPtr, 
ScreenPtr, void **);
 
 typedef Bool (*SetSharedPixmapBackingProcPtr)(PixmapPtr, void *);
 
+#define HAS_SYNC_SHARED_PIXMAP 1
+/* The SyncSharedPixmap hook has two purposes:
+ *
+ * 1. If the master driver has it, the slave driver can use it to
+ * synchronize the shared pixmap contents with the screen pixmap.
+ * 2. If the slave driver has it, the master driver can expect the slave
+ * driver to call the master screen's SyncSharedPixmap hook, so the master
+ * driver doesn't have to synchronize the shared pixmap contents itself,
+ * e.g. from the BlockHandler.
+ *
+ * A driver must only set the hook if it handles both cases correctly.
+ *
+ * The argument is the slave screen's pixmap_dirty_list entry, the hook is
+ * responsible for finding the corresponding entry in the master screen's
+ * pixmap_dirty_list.
+ */
+typedef void (*SyncSharedPixmapProcPtr)(PixmapDirtyUpdatePtr);
+
 typedef Bool (*StartPixmapTrackingProcPtr)(PixmapPtr, PixmapPtr,
int x, int y,
int dst_x, int dst_y,
@@ -616,6 +634,7 @@ typedef struct _Screen {
 
 StartPixmapTrackingProcPtr StartPixmapTracking;
 StopPixmapTrackingProcPtr StopPixmapTracking;
+SyncSharedPixmapProcPtr SyncSharedPixmap;
 
 SharedPixmapNotifyDamageProcPtr SharedPixmapNotifyDamage;
 RequestSharedPixmapNotifyDamageProcPtr RequestSharedPixmapNotifyDamage;
-- 
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: [PATCH xserver] randr: Do not check the screen size bound for gpu screens

2016-08-31 Thread Timo Aaltonen 

Any update on this?

On 20.06.2016 20:27, Hans de Goede wrote:
> Hi,
> 
> On 20-06-16 18:32, Nikhil Mahale wrote:
>> Sorry for late reply, Hans. See inline -
>>
>> On 06/13/2016 10:36 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 20-05-16 07:00, Nikhil Mahale wrote:
 For gpu screen, CrtcSet set/adjust the master screen size along
 mode in following callstack -

   ProcRRSetCrtcConfig()
 |
 -> RRCrtcSet()
 |
 -> rrCheckPixmapBounding()
 |
 -> pScrPriv->rrScreenSetSize()

 Checking screen size bound for gpus screen cause some configurations
 to fails, e.g

   $ xrandr --output eDP --mode 1920x1080 --pos 0x0 --output HDMI \
   --mode 2560x1440 --pos 0x0

   Here xrandr utility first sets screen size to 2560x1440 which
   gets resized to 1920x1080 on RRSetCrtcConfig request for eDP,
   and then RRSetCrtcConfig request for HDMI fails because
   of failure of screen bound check.
>>>
>>> Hmm, but one has the same problem when not using clone mode,
>>> then the master screen size must be made big enough to hold
>>> both crtc-s, so how come this has never been a problem then ?
>>>
>>> I've a feeling that in that case we end up doing things in
>>> finer grained steps. What if you do:
>>>
>>> $ xrandr --output eDP --mode 1920x1080 --pos 0x0
>>> $ xrandr --output HDMI --mode 2560x1440 --pos 0x0
>>>
>>> ? Does that work ?  If that works, which I would expect it will,
>>> then this should be fixed in the xrandr utility instead IMHO.
>>>
>>> Just circumventing the screen size check for slave outputs
>>> seem to go against the xrandr-1.2 spec to me.
>>>
>>> Also I guess one can reproduce the same problem without using
>>> slave-outputs, in which case your patch will not help.
>>>
>>
>> I don't think we could reproduce this problem without using slave-
>> output, because rrScreenSetSize() path which I explained in commit
>> message is not there, isn't it?
>>
>> Let me try to explain differece between both sequence of commands,
>> please correct me if required -
>>
>> $ xrandr --output eDP --mode 1920x1080 --pos 0x0 --output HDMI \
>> --mode 2560x1440 --pos 0x0
>>
>> ---
>> | Cmd | Screen size  |  eDP  | HDMI   |
>> ---
>> | RRSetScreenSize | 2560x1440| - |   -|
>> ---
>> | RRSetCrtcConfig | 1920x1080| 1920x1080 |   -|
>> | | changed from 2560x1440   |   ||
>> | | because of rrScreenSetSize() |   ||
>> | | path explained in commit |   ||
>> | | msg. (A) |   ||
>> ---
>> | RRSetCrtcConfig | 2560x1440| 1920x1080 | failed |
>> ---
> 
> Ah I see now, this will only happen when the eDP is a slave output,
> I was thinking that the HDMI would be a slave output, but that does
> not matter, this problem will happen independ of the HDMI being a normal
> or a slave output, as long as the eDP is a slave output.
> 
>> $ xrandr --output eDP --mode 1920x1080 --pos 0x0
>> $ xrandr --output HDMI --mode 2560x1440 --pos 0x0
>>
>>
>> 
>> | Cmd | Screen size|  eDP  | HDMI  |
>> 
>> | RRSetScreenSize | 1920x1080  | - |   -   |
>> 
>> | RRSetCrtcConfig | 1920x1080  | 1920x1080 |   -   |
>> 
>> | RRSetScreenSize | 2560x1440  | 1920x1080 |   -   |
>> 
>> | RRSetCrtcConfig | 2560x1440  | 1920x1080 | 2560x1440 |
>> 
>>
>> Case (A) is not there in second sequence of xrand commands, so you
>> could not reproduce problem.
> 
> Right, so you can get things to work without requiring a server change,
> iow this may be considered a xrandr utility bug, it could reproduce the
> sequence used in your second table, instead of skipping the second
> RRSetScreenSize.
> 
> OTOH this may indeed be a server bug, but your fix is not the right
> one, I wonder why we are doing a RRSetScreenSize for slave GPU-s at
> all. Since we already check that the Screen is big enough in
> ProcRRSetCrtcConfig?
> 
> I