[PATCH xserver] xfree86: drop KDSKBMUTE handling

2018-04-05 Thread Peter Hutterer 
This was never merged upstream. It was a Fedora kernel patch but dropped from
Fedora in 2013 with kernel 3.12.

The reason for the KDSKBMUTE proposal has been fixed in systemd in Feb 2013,
systemd 198.
https://lists.freedesktop.org/archives/systemd-devel/2013-February/008795.html

Signed-off-by: Peter Hutterer 
---
 hw/xfree86/os-support/linux/lnx_init.c | 26 --
 1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/hw/xfree86/os-support/linux/lnx_init.c 
b/hw/xfree86/os-support/linux/lnx_init.c
index 9e5ddcd50..a2464 100644
--- a/hw/xfree86/os-support/linux/lnx_init.c
+++ b/hw/xfree86/os-support/linux/lnx_init.c
@@ -46,10 +46,6 @@
 #define K_OFF 0x4
 #endif
 
-#ifndef KDSKBMUTE
-#define KDSKBMUTE 0x4B51
-#endif
-
 static Bool KeepTty = FALSE;
 static int activeVT = -1;
 
@@ -262,23 +258,18 @@ xf86OpenConsole(void)
 tcgetattr(xf86Info.consoleFd, _attr);
 SYSCALL(ioctl(xf86Info.consoleFd, KDGKBMODE, _mode));
 
-/* disable kernel special keys and buffering, new style */
-SYSCALL(ret = ioctl(xf86Info.consoleFd, KDSKBMUTE, 1));
+/* disable kernel special keys and buffering */
+SYSCALL(ret = ioctl(xf86Info.consoleFd, KDSKBMODE, K_OFF));
 if (ret < 0)
 {
-/* disable kernel special keys and buffering, old style */
-SYSCALL(ret = ioctl(xf86Info.consoleFd, KDSKBMODE, K_OFF));
+/* fine, just disable special keys */
+SYSCALL(ret = ioctl(xf86Info.consoleFd, KDSKBMODE, K_RAW));
 if (ret < 0)
-{
-/* fine, just disable special keys */
-SYSCALL(ret = ioctl(xf86Info.consoleFd, KDSKBMODE, K_RAW));
-if (ret < 0)
-FatalError("xf86OpenConsole: KDSKBMODE K_RAW failed 
%s\n",
-   strerror(errno));
+FatalError("xf86OpenConsole: KDSKBMODE K_RAW failed %s\n",
+   strerror(errno));
 
-/* ... and drain events, else the kernel gets angry */
-xf86SetConsoleHandler(drain_console, NULL);
-}
+/* ... and drain events, else the kernel gets angry */
+xf86SetConsoleHandler(drain_console, NULL);
 }
 
 nTty = tty_attr;
@@ -327,7 +318,6 @@ xf86CloseConsole(void)
 xf86Msg(X_WARNING, "xf86CloseConsole: KDSETMODE failed: %s\n",
 strerror(errno));
 
-SYSCALL(ioctl(xf86Info.consoleFd, KDSKBMUTE, 0));
 SYSCALL(ioctl(xf86Info.consoleFd, KDSKBMODE, tty_mode));
 tcsetattr(xf86Info.consoleFd, TCSANOW, _attr);
 
-- 
2.14.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: Fix page flipping under DRI 3.2.

2018-04-05 Thread Mario Kleiner 
I'm sorry to report it didn't fix it. This tested with current head of
xserver master, mesa master, so with my and your fixes included, and
apparently some new fixes from today.

Compositing under old Ubuntu Unity-7 == compiz and Gnome shell work
fine, as does KDE-5 Plasma with GLX+OpenGL compositing. Only
EGL+OpenGL is broken under DRI3. In KDE-5 you can use the kde system
settings app, select monitor settings, then tab "compositor" to switch
the compositing backend between GLX and EGL to test this.

-mario

On Wed, Apr 4, 2018 at 6:43 PM, Daniel Stone  wrote:
> Hi Mario,
>
> On 4 April 2018 at 17:40, Mario Kleiner  wrote:
>> On Wed, Apr 4, 2018 at 6:19 PM, Daniel Stone  wrote:
>>> Ugh. I've applied your pageflip patch, lfrb's two-patch atomic fix
>>> series and my fix-old-clients series, which for me fixes KDE running
>>> with both old and new Mesa. That's just running a Plasma 5 desktop
>>> with 'startkde', either single or dual head. Do things work for you if
>>> you have all those applied?
>>
>> I have all applied, but this new series "Fix modifier server / non-mod 
>> client"
>> of you: https://patchwork.freedesktop.org/series/41142/
>>
>> If that's the right one, i'll test it later today.
>
> Correct. If you could please try that series, that would be great. I
> did see KDE failing before that series, but it seems much happier now.
>
> Cheers,
> Daniel
___
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/8] GCC8 warning fixes

2018-04-05 Thread Adam Jackson 
On Thu, 2018-04-05 at 10:42 -0700, Keith Packard wrote:
> Adam Jackson  writes:
> 
> > gcc 8's buffer size logic got a bit pickier, in mostly reasonable ways,
> > but -Wmaybe-uninitialized got a lot more speculative. Regardless I'm
> > tired of seeing warnings in my build logs.
> 
> (some of these are truly ridiculous, but...)
> 
> Acked-by: Keith Packard 

remote: I: patch #215204 updated using rev 
4c1453393feaebd688571ed1ba16c21703119ced.
remote: I: patch #215205 updated using rev 
c3b190f9da3a8cd6f98c127220683dd20aed0f9b.
remote: I: patch #215210 updated using rev 
be99072a1a20af44d2457b8c86bd9041f61efa79.
remote: E: failed to find patch for rev 
176f26e96ab9958c84c98c88f31729d0240c420e.
remote: I: patch #215206 updated using rev 
d13cd3862e9ccd35c91a06680d02f2fc8fd03420.
remote: I: patch #215211 updated using rev 
83913de25d35709b3ab7b0ab124b73924145d2dd.
remote: I: patch #215207 updated using rev 
57e872301f5e836be2efb8f952f9c9711650b447.
remote: I: patch #215208 updated using rev 
6f0903ddc905f44272b85942323a467d82fef644.
remote: I: 7 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   99f9b077c6..6f0903ddc9  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: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

2018-04-05 Thread Mike Lothian 
Nope still not working

Intel DDX didn't launch, Modesetting did however compositing was disabled
due to the previous failure. Upon reenabling the screen went blank, however
things were still running, when I went to the top left corner I could see
the window titles, then the outline of the kicker menu too

On Thu, 5 Apr 2018 at 11:07 Mike Lothian  wrote:

> There's also some journalctl output in the bug report
>
> On 5 April 2018 at 11:06, Mike Lothian  wrote:
> > Hi
> >
> > I'm attaching the core dumps (4GB uncompressed, 7MB XZ compressed)
> >
> > Might still be too big for the list
> >
> > Cheers
> >
> > Mike
> >
> > On 5 April 2018 at 09:33, Daniel Stone  wrote:
> >> Hi Mike,
> >>
> >> On 5 April 2018 at 09:03, Mike Lothian  wrote:
> >>> I got different behavior with modesetting and the intel ddx
> >>
> >> I can try with the Intel DDX later on today.
> >>
> >>> Both didn't render anything, but I think one was crashing over and
> >>> over (I think systemd kept restarting it in quick succession)
> >>
> >> systemd should log core files to coredumpctl and maintain any output
> >> from services it's started itself in journalctl, so it would be great
> >> to see any output and segfaults if possible.
> >>
> >>> I only remember that because when I switched VTs it made it almost
> >>> impossible to type anything as it kept modesetting back to VT1 for a
> >>> moment
> >>>
> >>> That didn't happen with the latest patches (which all seem to be in
> >>> master now) but I did get the freeze that you saw
> >>
> >> Right, they are in master now. Which freeze do you mean? If you attach
> >> to the kwin process and see it blocked forever waiting on a reply in
> >> libICE/libSM, this seems to be related to KDE's session management
> >> getting itself tangled, and _not_ anything to do with the rendering
> >> path. For me, the hang inside libICE/libSM was caused by wiping out
> >> all the ksmserver processes still running, as well as my .ICE-unix
> >> directory.
> >>
> >> If you are seeing KWin and all the KDE session helper programs alive
> >> and _not_ blocked inside libICE/libSM, a black screen and a KDE mouse
> >> cursor, that's far more interesting and I'd also like to see the X
> >> server's log file as well as any output from KDE in journalctl.
> >>
> >>> Be aware that kwin detects when there have been rendering crashes or
> >>> incomplete starts and disables compositing. With compositing disabled
> >>> or set to Xrender everything starts fine
> >>
> >> I'm _extremely_ sure that I was using GL compositing, because I was
> >> seeing debug prints that I'd added to Mesa (and the X server DRI3
> >> requests called by Mesa) from a session running only KDE and nothing
> >> else. These debug prints were only ever called when you are an X11
> >> compositing manager.
> >>
> >> Cheers,
> >> Daniel
>
___
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/8] GCC8 warning fixes

2018-04-05 Thread Keith Packard 
Adam Jackson  writes:

> gcc 8's buffer size logic got a bit pickier, in mostly reasonable ways,
> but -Wmaybe-uninitialized got a lot more speculative. Regardless I'm
> tired of seeing warnings in my build logs.

(some of these are truly ridiculous, but...)

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

[PATCH xserver] xwayland: Silence a build warning if we can

2018-04-05 Thread Adam Jackson 
[735/786] Generating 
'hw/xwayland/Xwayland@exe/relative-pointer-unstable-v1-protocol.c'.
Using "code" is deprecated - use private-code or public-code.
See the help page for details.

Use private-code if wayland-scanner is new enough.

Signed-off-by: Adam Jackson 
---
 configure.ac|  4 
 hw/xwayland/Makefile.am | 14 +++---
 hw/xwayland/meson.build |  9 -
 3 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/configure.ac b/configure.ac
index 290721891d..d8d88e2b15 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2391,6 +2391,10 @@ if test "x$XWAYLAND" = xyes; then
AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner],,
 [${WAYLAND_PREFIX}/bin$PATH_SEPARATOR$PATH])
 
+PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner >= 1.14.91],
+  AC_SUBST(SCANNER_ARG, 'private-code'),
+  AC_SUBST(SCANNER_ARG, 'code'))
+
AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, `$PKG_CONFIG --variable=pkgdatadir 
wayland-protocols`)
 fi
 
diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am
index 3378a66569..0291afee79 100644
--- a/hw/xwayland/Makefile.am
+++ b/hw/xwayland/Makefile.am
@@ -79,36 +79,36 @@ relink:
$(AM_V_at)rm -f Xwayland$(EXEEXT) && $(MAKE) Xwayland$(EXEEXT)
 
 relative-pointer-unstable-v1-protocol.c : 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/relative-pointer/relative-pointer-unstable-v1.xml
-   $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
+   $(AM_V_GEN)$(WAYLAND_SCANNER) @SCANNER_ARG@ < $< > $@
 relative-pointer-unstable-v1-client-protocol.h : 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/relative-pointer/relative-pointer-unstable-v1.xml
$(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
 
 pointer-constraints-unstable-v1-protocol.c : 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
-   $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
+   $(AM_V_GEN)$(WAYLAND_SCANNER) @SCANNER_ARG@ < $< > $@
 pointer-constraints-unstable-v1-client-protocol.h : 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
$(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
 
 tablet-unstable-v2-protocol.c: 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/tablet/tablet-unstable-v2.xml
-   $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
+   $(AM_V_GEN)$(WAYLAND_SCANNER) @SCANNER_ARG@ < $< > $@
 tablet-unstable-v2-client-protocol.h: 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/tablet/tablet-unstable-v2.xml
$(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
 
 xwayland-keyboard-grab-unstable-v1-protocol.c : 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
-   $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
+   $(AM_V_GEN)$(WAYLAND_SCANNER) @SCANNER_ARG@ < $< > $@
 xwayland-keyboard-grab-unstable-v1-client-protocol.h : 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
$(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
 xdg-output-unstable-v1-protocol.c : 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/xdg-output/xdg-output-unstable-v1.xml
-   $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
+   $(AM_V_GEN)$(WAYLAND_SCANNER) @SCANNER_ARG@ < $< > $@
 xdg-output-unstable-v1-client-protocol.h : 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/xdg-output/xdg-output-unstable-v1.xml
$(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
 
 linux-dmabuf-unstable-v1-protocol.c : 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
-   $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
+   $(AM_V_GEN)$(WAYLAND_SCANNER) @SCANNER_ARG@ < $< > $@
 linux-dmabuf-unstable-v1-client-protocol.h : 
$(WAYLAND_PROTOCOLS_DATADIR)/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
$(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
 
 %-protocol.c : %.xml
-   $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
+   $(AM_V_GEN)$(WAYLAND_SCANNER) @SCANNER_ARG@ < $< > $@
 
 %-client-protocol.h : %.xml
$(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
diff --git a/hw/xwayland/meson.build b/hw/xwayland/meson.build
index 17f52b4bae..69a5c819a9 100644
--- a/hw/xwayland/meson.build
+++ b/hw/xwayland/meson.build
@@ -27,9 +27,16 @@ client_header = generator(scanner,
 output : '@BASENAME@-client-protocol.h',
 arguments : ['client-header', '@INPUT@', '@OUTPUT@']
 )
+
+if scanner_dep.version().version_compare('>= 1.14.91')
+scanner_argument = 'private-code'
+else
+scanner_argument = 'code'
+endif
+
 code = generator(scanner,
 output : '@BASENAME@-protocol.c',
-arguments : ['code', '@INPUT@', '@OUTPUT@']
+arguments : [scanner_argument, '@INPUT@', '@OUTPUT@']
 )
 srcs += client_header.process(relative_xml)
 srcs += client_header.process(pointer_xml)
-- 
2.16.2

___
xorg-devel@lists.x.org:

[PATCH xserver 2/8] dmx: Fix some snprintf warnings.

2018-04-05 Thread Adam Jackson 
snprintf doesn't terminate the string if it truncates, so things like
this are lurking crashers:

../hw/dmx/dmxprop.c: In function ‘dmxPropertyIdentifier.part.0’:
../hw/dmx/dmxprop.c:94:36: warning: ‘%s’ directive output may be truncated 
writing up to 255 bytes into a region of size 123 [-Wformat-truncation=]
 snprintf(buf, sizeof(buf), "%s:%s:%s", DMX_IDENT, hostname, display);
^~ 
../hw/dmx/dmxprop.c:94:5: note: ‘snprintf’ output 7 or more bytes (assuming 
262) into a destination of size 128
 snprintf(buf, sizeof(buf), "%s:%s:%s", DMX_IDENT, hostname, display);
 ^~~~
../hw/dmx/dmxprop.c: In function ‘dmxPropertyWindow’:
../hw/dmx/dmxprop.c:372:36: warning: ‘%d’ directive output may be truncated 
writing between 1 and 11 bytes into a region of size between 0 and 127 
[-Wformat-truncation=]
 snprintf(buf, sizeof(buf), "%s,%d", id, dmxScreen->index);
^~
../hw/dmx/dmxprop.c:372:5: note: ‘snprintf’ output between 3 and 140 bytes into 
a destination of size 128
 snprintf(buf, sizeof(buf), "%s,%d", id, dmxScreen->index);
 ^

We could be more precise about termination, but meh.

Signed-off-by: Adam Jackson 
---
 hw/dmx/dmxprop.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/dmx/dmxprop.c b/hw/dmx/dmxprop.c
index 4c85268b79..7dfa04af5a 100644
--- a/hw/dmx/dmxprop.c
+++ b/hw/dmx/dmxprop.c
@@ -84,7 +84,7 @@ dmxPropertyIdentifier(void)
 /* RATS: These buffers are only used in
  * length-limited calls. */
 char hostname[256];
-static char buf[128];
+static char buf[512];
 static int initialized = 0;
 
 if (initialized++)
@@ -346,7 +346,7 @@ dmxPropertyWindow(DMXScreenInfo * dmxScreen)
 Display *dpy = dmxScreen->beDisplay;
 Window win = dmxScreen->scrnWin;
 DMXScreenInfo *other;
-char buf[128];  /* RATS: only used with snprintf */
+char buf[1024];  /* RATS: only used with snprintf */
 
 if (!dpy)
 return; /* FIXME: What should be done here if Xdmx is 
started
-- 
2.16.2

___
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 4/8] dmx: Clean up some argument parsing code

2018-04-05 Thread Adam Jackson 
This threw:

../hw/dmx/input/dmxarg.c: In function ‘dmxArgParse’:
../hw/dmx/input/dmxarg.c:128:5: warning: ‘strncpy’ specified bound depends on 
the length of the source argument [-Wstringop-overflow=]
 strncpy(tmp, string, len);
 ^
../hw/dmx/input/dmxarg.c:126:11: note: length computed here
 len = strlen(string) + 2;
   ^~

This code predates xstrtokenize, but that's no excuse.

Signed-off-by: Adam Jackson 
---
 hw/dmx/input/dmxarg.c | 23 +--
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/hw/dmx/input/dmxarg.c b/hw/dmx/input/dmxarg.c
index 6c21ae959a..582ed3faa6 100644
--- a/hw/dmx/input/dmxarg.c
+++ b/hw/dmx/input/dmxarg.c
@@ -114,30 +114,17 @@ dmxArgC(dmxArg a)
 dmxArg
 dmxArgParse(const char *string)
 {
-char *tmp;
-char *start, *pt;
+int i = 0;
 dmxArg a = dmxArgCreate();
-int done;
-int len;
 
 if (!string)
 return a;
 
-len = strlen(string) + 2;
-tmp = malloc(len);
-strncpy(tmp, string, len);
+a->argv = (const char **)xstrtokenize(string, ",");
+if (a->argv)
+for (i = 0; a->argv[i] != NULL; i++);
+a->argc = i;
 
-for (start = pt = tmp, done = 0; !done && *pt; start = ++pt) {
-for (; *pt && *pt != ','; pt++);
-if (!*pt)
-done = 1;
-*pt = '\0';
-dmxArgAdd(a, start);
-}
-if (!done)
-dmxArgAdd(a, "");   /* Final comma */
-
-free(tmp);
 return a;
 }
 
-- 
2.16.2

___
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 0/8] GCC8 warning fixes

2018-04-05 Thread Adam Jackson 
gcc 8's buffer size logic got a bit pickier, in mostly reasonable ways,
but -Wmaybe-uninitialized got a lot more speculative. Regardless I'm
tired of seeing warnings in my build logs.

- ajax

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

[PATCH xserver 3/8] dmx: Fix a read-from-uninitialized warning

2018-04-05 Thread Adam Jackson 
../hw/dmx/dmxpixmap.c: In function ‘dmxBitmapToRegion’:
../include/regionstr.h:174:22: warning: ‘Box.x1’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
 (_pReg)->extents = *(_pBox);
 ~^~
../hw/dmx/dmxpixmap.c:208:12: note: ‘Box.x1’ was declared here
 BoxRec Box;
^~~

Signed-off-by: Adam Jackson 
---
 hw/dmx/dmxpixmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/dmx/dmxpixmap.c b/hw/dmx/dmxpixmap.c
index 17aca9224b..7b317eaef1 100644
--- a/hw/dmx/dmxpixmap.c
+++ b/hw/dmx/dmxpixmap.c
@@ -205,7 +205,7 @@ dmxBitmapToRegion(PixmapPtr pPixmap)
 RegionPtr pReg, pTmpReg;
 int x, y;
 unsigned long previousPixel, currentPixel;
-BoxRec Box;
+BoxRec Box = { 0, };
 Bool overlap;
 
 if (!dmxScreen->beDisplay) {
-- 
2.16.2

___
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 8/8] dix: Hush an almost certainly bogus warning

2018-04-05 Thread Adam Jackson 
../dix/getevents.c: In function ‘transformAbsolute’:
../dix/getevents.c:1195:28: warning: ‘oy’ may be used uninitialized in this 
function [-Wmaybe-uninitialized]
 struct pixman_f_vector p = {.v = {*x, *y, 1} };
^
../dix/getevents.c:1234:22: note: ‘oy’ was declared here
 double x, y, ox, oy;
  ^~

This one is truly special. Even though both ox and oy are set and read
along the same paths, only oy is marked for this warning! Initializing
just oy = 0.0 fixes it entirely, but let's not make a weird thing
weirder.

Signed-off-by: Adam Jackson 
---
 dix/getevents.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dix/getevents.c b/dix/getevents.c
index 0d87453e5d..d8955969ab 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -1231,7 +1231,7 @@ transformRelative(DeviceIntPtr dev, ValuatorMask *mask)
 static void
 transformAbsolute(DeviceIntPtr dev, ValuatorMask *mask)
 {
-double x, y, ox, oy;
+double x, y, ox = 0.0, oy = 0.0;
 int has_x, has_y;
 
 has_x = valuator_mask_isset(mask, 0);
-- 
2.16.2

___
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 6/8] xkb: Silence some compiler warnings

2018-04-05 Thread Adam Jackson 
Of the form:

../xkb/XKBGAlloc.c: In function ‘SrvXkbAddGeomKeyAlias’:
../xkb/XKBGAlloc.c:591:13: warning: ‘strncpy’ specified bound 4 equals 
destination size [-Wstringop-truncation]
 strncpy(alias->real, realStr, XkbKeyNameLength);
 ^~~

This is intentional; the code that reads from these fields never reads
more than 4 bytes anyway. Rephrase things in terms of memcpy so that's
clear. Obviously this is awful but in XKB awful is par.

Signed-off-by: Adam Jackson 
---
 xkb/XKBGAlloc.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/xkb/XKBGAlloc.c b/xkb/XKBGAlloc.c
index e9f55fa434..8958b0c523 100644
--- a/xkb/XKBGAlloc.c
+++ b/xkb/XKBGAlloc.c
@@ -588,7 +588,8 @@ XkbAddGeomKeyAlias(XkbGeometryPtr geom, char *aliasStr, 
char *realStr)
  i++, alias++) {
 if (strncmp(alias->alias, aliasStr, XkbKeyNameLength) == 0) {
 memset(alias->real, 0, XkbKeyNameLength);
-strncpy(alias->real, realStr, XkbKeyNameLength);
+memcpy(alias->real, realStr,
+   min(XkbKeyNameLength, strlen(realStr)));
 return alias;
 }
 }
@@ -598,8 +599,8 @@ XkbAddGeomKeyAlias(XkbGeometryPtr geom, char *aliasStr, 
char *realStr)
 }
 alias = >key_aliases[geom->num_key_aliases];
 memset(alias, 0, sizeof(XkbKeyAliasRec));
-strncpy(alias->alias, aliasStr, XkbKeyNameLength);
-strncpy(alias->real, realStr, XkbKeyNameLength);
+memcpy(alias->alias, aliasStr, min(XkbKeyNameLength, strlen(aliasStr)));
+memcpy(alias->real, realStr, min(XkbKeyNameLength, strlen(realStr)));
 geom->num_key_aliases++;
 return alias;
 }
@@ -814,8 +815,8 @@ XkbAddGeomOverlayKey(XkbOverlayPtr overlay,
 (_XkbAllocOverlayKeys(row, 1) != Success))
 return NULL;
 key = >keys[row->num_keys];
-strncpy(key->under.name, under, XkbKeyNameLength);
-strncpy(key->over.name, over, XkbKeyNameLength);
+memcpy(key->under.name, under, min(XkbKeyNameLength, strlen(under)));
+memcpy(key->over.name, over, min(XkbKeyNameLength, strlen(over)));
 row->num_keys++;
 return key;
 }
-- 
2.16.2

___
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 7/8] mi: Hush an almost certainly bogus warning

2018-04-05 Thread Adam Jackson 
In file included from ../mi/miexpose.c:83:
../mi/miexpose.c: In function ‘miHandleExposures’:
../include/regionstr.h:174:22: warning: ‘expBox.y2’ may be used uninitialized 
in this function [-Wmaybe-uninitialized]
 (_pReg)->extents = *(_pBox);
 ~^~
../mi/miexpose.c:139:12: note: ‘expBox.y2’ was declared here
 BoxRec expBox;
^~

etc. It's initialized if (extents), and then only read if (extents),
but gcc doesn't seem to figure that out. Whatever, bzero it to be
explicit.

Signed-off-by: Adam Jackson 
---
 mi/miexpose.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mi/miexpose.c b/mi/miexpose.c
index 148d1a63b8..c34530c347 100644
--- a/mi/miexpose.c
+++ b/mi/miexpose.c
@@ -136,7 +136,7 @@ miHandleExposures(DrawablePtr pSrcDrawable, DrawablePtr 
pDstDrawable,
the window background
  */
 WindowPtr pSrcWin;
-BoxRec expBox;
+BoxRec expBox = { 0, };
 Bool extents;
 
 /* avoid work if we can */
-- 
2.16.2

___
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 5/8] dmx: Silence a string truncation warning.

2018-04-05 Thread Adam Jackson 
../hw/dmx/config/dmxparse.c: In function ‘dmxConfigCreateOption’:
../hw/dmx/config/dmxparse.c:385:13: warning: ‘strncpy’ output truncated before 
terminating nul copying as many bytes from a string as its length 
[-Wstringop-truncation]
 strncpy(option->string + offset, p->string, len);
 ^~~~
../hw/dmx/config/dmxparse.c:383:23: note: length computed here
 int len = strlen(p->string);
   ^

The thing it's warning about is intentional, the surrounding code does
its own nul-termination. Make that obvious by using memcpy instead.

Signed-off-by: Adam Jackson 
---
 hw/dmx/config/dmxparse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/dmx/config/dmxparse.c b/hw/dmx/config/dmxparse.c
index cf510844d6..f66143a6a5 100644
--- a/hw/dmx/config/dmxparse.c
+++ b/hw/dmx/config/dmxparse.c
@@ -382,7 +382,7 @@ dmxConfigCreateOption(DMXConfigTokenPtr pStart,
 if (p->string) {
 int len = strlen(p->string);
 
-strncpy(option->string + offset, p->string, len);
+memcpy(option->string + offset, p->string, len);
 offset += len;
 if (p->next)
 option->string[offset++] = ' ';
-- 
2.16.2

___
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 1/8] gtf: Warning fix

2018-04-05 Thread Adam Jackson 
../hw/xfree86/utils/gtf/gtf.c: In function ‘print_fb_mode’:
../hw/xfree86/utils/gtf/gtf.c:241:50: warning: cast from function call of type 
‘double’ to non-matching type ‘int’ [-Wbad-function-cast]
 printf("timings %d %d %d %d %d %d %d\n", (int) rint(100.0 / 
m->pclk),   /* pixclock in picoseconds */

That's pretty nitpicky of you, gcc, but at least it's easy to fix.

Signed-off-by: Adam Jackson 
---
 hw/xfree86/utils/gtf/gtf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/xfree86/utils/gtf/gtf.c b/hw/xfree86/utils/gtf/gtf.c
index c31bc8f938..818ee0fd7a 100644
--- a/hw/xfree86/utils/gtf/gtf.c
+++ b/hw/xfree86/utils/gtf/gtf.c
@@ -238,7 +238,7 @@ print_fb_mode(mode * m)
 printf("# PCLK: %.2f MHz, H: %.2f kHz, V: %.2f Hz\n",
m->pclk, m->h_freq, m->v_freq);
 printf("geometry %d %d %d %d 32\n", m->hr, m->vr, m->hr, m->vr);
-printf("timings %d %d %d %d %d %d %d\n", (int) rint(100.0 / 
m->pclk),   /* pixclock in picoseconds */
+printf("timings %d %d %d %d %d %d %d\n", (int)lrint(100.0 / 
m->pclk),   /* pixclock in picoseconds */
m->hfl - m->hse, /* left margin (in pixels) */
m->hss - m->hr,  /* right margin (in pixels) */
m->vfl - m->vse, /* upper margin (in pixel lines) */
-- 
2.16.2

___
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 v3 3/3] modesetting: Actually get framebuffer ID

2018-04-05 Thread Adam Jackson 
On Thu, 2018-04-05 at 18:01 +0200, Olivier Fourdan wrote:
> 
> On 5 April 2018 at 17:47, Daniel Stone  wrote:
> > We would fail to get the FB ID if it wasn't already imported, since we
> > were checking to see if the pointer was NULL (it never was) rather than
> > if the content of the pointer was 0.
> > 
> > Signed-off-by: Daniel Stone 
> > Reported-by: Olivier Fourdan 
> > ---
> >  hw/xfree86/drivers/modesetting/drmmode_display.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
> > b/hw/xfree86/drivers/modesetting/drmmode_display.c
> > index cdcd4f3f3..322ef050b 100644
> > --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> > +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> > @@ -624,7 +624,7 @@ drmmode_crtc_get_fb_id(xf86CrtcPtr crtc, uint32_t 
> > *fb_id, int *x, int *y)
> >  *y = crtc->y;
> >  }
> > 
> > -if (fb_id == 0) {
> > +if (*fb_id == 0) {
> >  ret = drmmode_bo_import(drmmode, >front_bo,
> >  >fb_id);
> >  if (ret < 0) {
> > --
> > 2.16.3
> > 
> > 
> 
> 
> LGTM, Thanks!
> 
> Tested-by: Olivier Fourdan 
> Reviewed-by: Olivier Fourdan 

Merged:

remote: I: patch #215199 updated using rev 
99f9b077c62e14ba955b9c1f7afda47f7799d317.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   8ff1cdb2bf..99f9b077c6  master -> master

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

Re: [PATCH xserver v3 3/3] modesetting: Actually get framebuffer ID

2018-04-05 Thread Michel Dänzer 
On 2018-04-05 05:47 PM, Daniel Stone wrote:
> We would fail to get the FB ID if it wasn't already imported, since we
> were checking to see if the pointer was NULL (it never was) rather than
> if the content of the pointer was 0.
> 
> Signed-off-by: Daniel Stone 
> Reported-by: Olivier Fourdan 
> ---
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index cdcd4f3f3..322ef050b 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -624,7 +624,7 @@ drmmode_crtc_get_fb_id(xf86CrtcPtr crtc, uint32_t *fb_id, 
> int *x, int *y)
>  *y = crtc->y;
>  }
>  
> -if (fb_id == 0) {
> +if (*fb_id == 0) {
>  ret = drmmode_bo_import(drmmode, >front_bo,
>  >fb_id);
>  if (ret < 0) {
> 

Reviewed-and-Tested-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 v3 3/3] modesetting: Actually get framebuffer ID

2018-04-05 Thread Olivier Fourdan 
On 5 April 2018 at 17:47, Daniel Stone  wrote:

> We would fail to get the FB ID if it wasn't already imported, since we
> were checking to see if the pointer was NULL (it never was) rather than
> if the content of the pointer was 0.
>
> Signed-off-by: Daniel Stone 
> Reported-by: Olivier Fourdan 
> ---
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index cdcd4f3f3..322ef050b 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -624,7 +624,7 @@ drmmode_crtc_get_fb_id(xf86CrtcPtr crtc, uint32_t
> *fb_id, int *x, int *y)
>  *y = crtc->y;
>  }
>
> -if (fb_id == 0) {
> +if (*fb_id == 0) {
>  ret = drmmode_bo_import(drmmode, >front_bo,
>  >fb_id);
>  if (ret < 0) {
> --
> 2.16.3
>
>

LGTM, Thanks!

Tested-by: Olivier Fourdan 
Reviewed-by: Olivier Fourdan 

Cheers,
O.
___
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 v3 3/3] modesetting: Actually get framebuffer ID

2018-04-05 Thread Daniel Stone 
We would fail to get the FB ID if it wasn't already imported, since we
were checking to see if the pointer was NULL (it never was) rather than
if the content of the pointer was 0.

Signed-off-by: Daniel Stone 
Reported-by: Olivier Fourdan 
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index cdcd4f3f3..322ef050b 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -624,7 +624,7 @@ drmmode_crtc_get_fb_id(xf86CrtcPtr crtc, uint32_t *fb_id, 
int *x, int *y)
 *y = crtc->y;
 }
 
-if (fb_id == 0) {
+if (*fb_id == 0) {
 ret = drmmode_bo_import(drmmode, >front_bo,
 >fb_id);
 if (ret < 0) {
-- 
2.16.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 xserver v3 1/3] modesetting: Don't reuse iterator in nested loop

2018-04-05 Thread Daniel Stone 
drmmode_crtc_set_mode has a loop nested inside another loop, where both
of them were using 'i' as the loop iterator. Rename it to avoid an
infinite loop.

Signed-off-by: Daniel Stone 
Reported-by: Michel Dänzer 
Reviewed-by: Michel Dänzer 
Tested-by: Michel Dänzer 
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 2b04c3555..cdcd4f3f3 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -777,12 +777,13 @@ drmmode_crtc_set_mode(xf86CrtcPtr crtc, Bool test_only)
 drmmode_crtc_private_ptr other_drmmode_crtc = 
other_crtc->driver_private;
 int lost_outputs = 0;
 int remaining_outputs = 0;
+int j;
 
 if (other_crtc == crtc)
 continue;
 
-for (i = 0; i < xf86_config->num_output; i++) {
-xf86OutputPtr output = xf86_config->output[i];
+for (j = 0; j < xf86_config->num_output; j++) {
+xf86OutputPtr output = xf86_config->output[j];
 drmmode_output_private_ptr drmmode_output = 
output->driver_private;
 
 if (drmmode_output->current_crtc == other_crtc) {
-- 
2.16.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 xserver v3 2/3] dri3: Set stride and size for old clients

2018-04-05 Thread Daniel Stone 
For old clients using the fd_from_pixmap entrypoint, make sure we set
stride and size correctly.

Noticed by inspection.

Signed-off-by: Daniel Stone 
---
 dri3/dri3_screen.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index 41595f412..8ccbeb40c 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -161,6 +161,8 @@ dri3_fd_from_pixmap(PixmapPtr pixmap, CARD16 *stride, 
CARD32 *size)
 return -1;
 }
 
+*stride = strides[0];
+*size = size[0];
 return fds[0];
 }
 
-- 
2.16.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 1/2] modesetting: Don't reuse iterator in nested loop

2018-04-05 Thread Michel Dänzer 
On 2018-04-05 03:58 PM, Daniel Stone wrote:
> drmmode_crtc_set_mode has a loop nested inside another loop, where both
> of them were using 'i' as the loop iterator. Rename it to avoid an
> infinite loop.
> 
> Signed-off-by: Daniel Stone 
> Reported-by: Michel Dänzer 
> ---
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index 0eacefba2..f5f9fa582 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -778,12 +778,13 @@ drmmode_crtc_set_mode(xf86CrtcPtr crtc, Bool test_only)
>  drmmode_crtc_private_ptr other_drmmode_crtc = 
> other_crtc->driver_private;
>  int lost_outputs = 0;
>  int remaining_outputs = 0;
> + int j;

Indentation looks wrong here.


With that and the bug pointed out by others fixed,

Reviewed-and-Tested-by: Michel Dänzer 


Note that it still fails to actually light up for me with amdgpu DC
though, drmModeAtomicCommit returns -EINVAL. I'm afraid no bandwidth
right now (or indeed for a while) to help with looking into that, other
than maybe occasionally testing patches. Adding the amd-gfx list, as
this might be a DC issue.

OTOH it fails to light up with the radeon kernel driver as well,
drmModeSetCrtc returns -ENOENT.


-- 
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 1/2] modesetting: Don't reuse iterator in nested loop

2018-04-05 Thread Walter Harms 


> Daniel Stone  hat am 5. April 2018 um 16:08 geschrieben:
> 
> 
> On 5 April 2018 at 15:06, Walter Harms  wrote:
> >> Daniel Stone  hat am 5. April 2018 um 15:58
> >> geschrieben:
> >> -for (i = 0; i < xf86_config->num_output; i++) {
> >> -xf86OutputPtr output = xf86_config->output[i];
> >> +for (j = 0; i < xf86_config->num_output; j++) {
> >> +xf86OutputPtr output = xf86_config->output[j];
> >
> > Your intention is to loop over J but terminate with i ?
> > that is at least confusing.
> 
> Today really isn't my day. Apologies.


on the positiv side somebody is actualy reading the code  :)

re,
 wh
___
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/2] modesetting: Don't reuse iterator in nested loop

2018-04-05 Thread Olivier Fourdan 
On Thu, Apr 5, 2018 at 3:58 PM, Daniel Stone  wrote:

> drmmode_crtc_set_mode has a loop nested inside another loop, where both
> of them were using 'i' as the loop iterator. Rename it to avoid an
> infinite loop.
>
> Signed-off-by: Daniel Stone 
> Reported-by: Michel Dänzer 
> ---
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index 0eacefba2..f5f9fa582 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -778,12 +778,13 @@ drmmode_crtc_set_mode(xf86CrtcPtr crtc, Bool
> test_only)
>  drmmode_crtc_private_ptr other_drmmode_crtc =
> other_crtc->driver_private;
>  int lost_outputs = 0;
>  int remaining_outputs = 0;
> +   int j;
>
>  if (other_crtc == crtc)
>  continue;
>
> -for (i = 0; i < xf86_config->num_output; i++) {
> -xf86OutputPtr output = xf86_config->output[i];
> +for (j = 0; i < xf86_config->num_output; j++) {
>

 You mean j < xf86_config->num_output here :)


> +xf86OutputPtr output = xf86_config->output[j];
>  drmmode_output_private_ptr drmmode_output =
> output->driver_private;
>
>  if (drmmode_output->current_crtc == other_crtc) {
> --
> 2.17.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
___
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/2] modesetting: Don't reuse iterator in nested loop

2018-04-05 Thread Daniel Stone 
On 5 April 2018 at 15:06, Walter Harms  wrote:
>> Daniel Stone  hat am 5. April 2018 um 15:58
>> geschrieben:
>> -for (i = 0; i < xf86_config->num_output; i++) {
>> -xf86OutputPtr output = xf86_config->output[i];
>> +for (j = 0; i < xf86_config->num_output; j++) {
>> +xf86OutputPtr output = xf86_config->output[j];
>
> Your intention is to loop over J but terminate with i ?
> that is at least confusing.

Today really isn't my day. Apologies.
___
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/2] modesetting: Don't reuse iterator in nested loop

2018-04-05 Thread Walter Harms 


> Daniel Stone  hat am 5. April 2018 um 15:58
> geschrieben:
> 
> 
> drmmode_crtc_set_mode has a loop nested inside another loop, where both
> of them were using 'i' as the loop iterator. Rename it to avoid an
> infinite loop.
> 
> Signed-off-by: Daniel Stone 
> Reported-by: Michel Dänzer 
> ---
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index 0eacefba2..f5f9fa582 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -778,12 +778,13 @@ drmmode_crtc_set_mode(xf86CrtcPtr crtc, Bool test_only)
>  drmmode_crtc_private_ptr other_drmmode_crtc =
> other_crtc->driver_private;
>  int lost_outputs = 0;
>  int remaining_outputs = 0;
> + int j;
>  
>  if (other_crtc == crtc)
>  continue;
>  
> -for (i = 0; i < xf86_config->num_output; i++) {
> -xf86OutputPtr output = xf86_config->output[i];
> +for (j = 0; i < xf86_config->num_output; j++) {
> +xf86OutputPtr output = xf86_config->output[j];

Your intention is to loop over J but terminate with i ?
that is at least confusing.

re,
 wh


>  drmmode_output_private_ptr drmmode_output =
> output->driver_private;
>  
>  if (drmmode_output->current_crtc == other_crtc) {
> -- 
> 2.17.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
___
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 v2 2/2] dri3: Set stride and size for old clients

2018-04-05 Thread Daniel Stone 
For old clients using the fd_from_pixmap entrypoint, make sure we set
stride and size correctly.

Noticed by inspection.

Signed-off-by: Daniel Stone 
---
 dri3/dri3_screen.c | 2 ++
 1 file changed, 2 insertions(+)

Sorry, accidentally sent the previous without having committed the fix.

diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index 41595f412..8ccbeb40c 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -161,6 +161,8 @@ dri3_fd_from_pixmap(PixmapPtr pixmap, CARD16 *stride, 
CARD32 *size)
 return -1;
 }
 
+*stride = strides[0];
+*size = size[0];
 return fds[0];
 }
 
-- 
2.17.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

[PATCH xserver 2/2] dri3: Set stride and size for old clients

2018-04-05 Thread Daniel Stone 
For old clients using the fd_from_pixmap entrypoint, make sure we set
stride and size correctly.

Noticed by inspection.

Signed-off-by: Daniel Stone 
---
 dri3/dri3_screen.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/dri3/dri3_screen.c b/dri3/dri3_screen.c
index 41595f412..a111ee50f 100644
--- a/dri3/dri3_screen.c
+++ b/dri3/dri3_screen.c
@@ -161,6 +161,8 @@ dri3_fd_from_pixmap(PixmapPtr pixmap, CARD16 *stride, 
CARD32 *size)
 return -1;
 }
 
+*stride = strides[0];
+*size = sizes[0];
 return fds[0];
 }
 
-- 
2.17.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

[PATCH xserver 1/2] modesetting: Don't reuse iterator in nested loop

2018-04-05 Thread Daniel Stone 
drmmode_crtc_set_mode has a loop nested inside another loop, where both
of them were using 'i' as the loop iterator. Rename it to avoid an
infinite loop.

Signed-off-by: Daniel Stone 
Reported-by: Michel Dänzer 
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 0eacefba2..f5f9fa582 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -778,12 +778,13 @@ drmmode_crtc_set_mode(xf86CrtcPtr crtc, Bool test_only)
 drmmode_crtc_private_ptr other_drmmode_crtc = 
other_crtc->driver_private;
 int lost_outputs = 0;
 int remaining_outputs = 0;
+   int j;
 
 if (other_crtc == crtc)
 continue;
 
-for (i = 0; i < xf86_config->num_output; i++) {
-xf86OutputPtr output = xf86_config->output[i];
+for (j = 0; i < xf86_config->num_output; j++) {
+xf86OutputPtr output = xf86_config->output[j];
 drmmode_output_private_ptr drmmode_output = 
output->driver_private;
 
 if (drmmode_output->current_crtc == other_crtc) {
-- 
2.17.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: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

2018-04-05 Thread Mike Lothian 
There's also some journalctl output in the bug report

On 5 April 2018 at 11:06, Mike Lothian  wrote:
> Hi
>
> I'm attaching the core dumps (4GB uncompressed, 7MB XZ compressed)
>
> Might still be too big for the list
>
> Cheers
>
> Mike
>
> On 5 April 2018 at 09:33, Daniel Stone  wrote:
>> Hi Mike,
>>
>> On 5 April 2018 at 09:03, Mike Lothian  wrote:
>>> I got different behavior with modesetting and the intel ddx
>>
>> I can try with the Intel DDX later on today.
>>
>>> Both didn't render anything, but I think one was crashing over and
>>> over (I think systemd kept restarting it in quick succession)
>>
>> systemd should log core files to coredumpctl and maintain any output
>> from services it's started itself in journalctl, so it would be great
>> to see any output and segfaults if possible.
>>
>>> I only remember that because when I switched VTs it made it almost
>>> impossible to type anything as it kept modesetting back to VT1 for a
>>> moment
>>>
>>> That didn't happen with the latest patches (which all seem to be in
>>> master now) but I did get the freeze that you saw
>>
>> Right, they are in master now. Which freeze do you mean? If you attach
>> to the kwin process and see it blocked forever waiting on a reply in
>> libICE/libSM, this seems to be related to KDE's session management
>> getting itself tangled, and _not_ anything to do with the rendering
>> path. For me, the hang inside libICE/libSM was caused by wiping out
>> all the ksmserver processes still running, as well as my .ICE-unix
>> directory.
>>
>> If you are seeing KWin and all the KDE session helper programs alive
>> and _not_ blocked inside libICE/libSM, a black screen and a KDE mouse
>> cursor, that's far more interesting and I'd also like to see the X
>> server's log file as well as any output from KDE in journalctl.
>>
>>> Be aware that kwin detects when there have been rendering crashes or
>>> incomplete starts and disables compositing. With compositing disabled
>>> or set to Xrender everything starts fine
>>
>> I'm _extremely_ sure that I was using GL compositing, because I was
>> seeing debug prints that I'd added to Mesa (and the X server DRI3
>> requests called by Mesa) from a session running only KDE and nothing
>> else. These debug prints were only ever called when you are an X11
>> compositing manager.
>>
>> Cheers,
>> Daniel
___
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: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

2018-04-05 Thread Daniel Stone 
Hi Mike,

On 5 April 2018 at 09:03, Mike Lothian  wrote:
> I got different behavior with modesetting and the intel ddx

I can try with the Intel DDX later on today.

> Both didn't render anything, but I think one was crashing over and
> over (I think systemd kept restarting it in quick succession)

systemd should log core files to coredumpctl and maintain any output
from services it's started itself in journalctl, so it would be great
to see any output and segfaults if possible.

> I only remember that because when I switched VTs it made it almost
> impossible to type anything as it kept modesetting back to VT1 for a
> moment
>
> That didn't happen with the latest patches (which all seem to be in
> master now) but I did get the freeze that you saw

Right, they are in master now. Which freeze do you mean? If you attach
to the kwin process and see it blocked forever waiting on a reply in
libICE/libSM, this seems to be related to KDE's session management
getting itself tangled, and _not_ anything to do with the rendering
path. For me, the hang inside libICE/libSM was caused by wiping out
all the ksmserver processes still running, as well as my .ICE-unix
directory.

If you are seeing KWin and all the KDE session helper programs alive
and _not_ blocked inside libICE/libSM, a black screen and a KDE mouse
cursor, that's far more interesting and I'd also like to see the X
server's log file as well as any output from KDE in journalctl.

> Be aware that kwin detects when there have been rendering crashes or
> incomplete starts and disables compositing. With compositing disabled
> or set to Xrender everything starts fine

I'm _extremely_ sure that I was using GL compositing, because I was
seeing debug prints that I'd added to Mesa (and the X server DRI3
requests called by Mesa) from a session running only KDE and nothing
else. These debug prints were only ever called when you are an X11
compositing manager.

Cheers,
Daniel
___
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: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

2018-04-05 Thread Mike Lothian 
Hi

I got different behavior with modesetting and the intel ddx

Both didn't render anything, but I think one was crashing over and
over (I think systemd kept restarting it in quick succession)

I only remember that because when I switched VTs it made it almost
impossible to type anything as it kept modesetting back to VT1 for a
moment

That didn't happen with the latest patches (which all seem to be in
master now) but I did get the freeze that you saw

Be aware that kwin detects when there have been rendering crashes or
incomplete starts and disables compositing. With compositing disabled
or set to Xrender everything starts fine

Cheers

Mike

On Thu, 5 Apr 2018 at 08:58 Daniel Stone  wrote:
>
> Hi Mike,
>
> On 5 April 2018 at 07:10, Mike Lothian  wrote:
> > I've just tested with those patches, it still doesn't work without that 
> > revert
> >
> > If you're testing this on kwin can you make sure you're using one of
> > the OpenGL options on the renderer rather than XRender
>
> I'm absolutely certain it was using OpenGL because it hit all my debug
> prints. I was using KF5-Plasma from Fedora 28: which version did you
> have? When you say 'doesn't seem to start', what happens exactly?
> Before my last patchset, I saw the KDE cursor but no content rendered.
> After applying all three patch series (10 patches total) it started
> fine, but it had in the meantime got into some weird in-between state
> where KWin hung waiting for an ICE/SM message which never returned. I
> had to kill several stray ksmserver processes and also wipe out my
> .ICE-unix directory.
>
> Cheers,
> Daniel
___
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: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

2018-04-05 Thread Daniel Stone 
Hi Mike,

On 5 April 2018 at 07:10, Mike Lothian  wrote:
> I've just tested with those patches, it still doesn't work without that revert
>
> If you're testing this on kwin can you make sure you're using one of
> the OpenGL options on the renderer rather than XRender

I'm absolutely certain it was using OpenGL because it hit all my debug
prints. I was using KF5-Plasma from Fedora 28: which version did you
have? When you say 'doesn't seem to start', what happens exactly?
Before my last patchset, I saw the KDE cursor but no content rendered.
After applying all three patch series (10 patches total) it started
fine, but it had in the meantime got into some weird in-between state
where KWin hung waiting for an ICE/SM message which never returned. I
had to kill several stray ksmserver processes and also wipe out my
.ICE-unix directory.

Cheers,
Daniel
___
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: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

2018-04-05 Thread Mike Lothian 
Hi

I've just tested with those patches, it still doesn't work without that revert

If you're testing this on kwin can you make sure you're using one of
the OpenGL options on the renderer rather than XRender

Thanks

Mike

On 4 April 2018 at 17:17, Daniel Stone  wrote:
> Hi Mike,
>
> On 4 April 2018 at 09:12, Mike Lothian  wrote:
>> Kwin doesn't seem to start with the following commit:
>>
>> commit abb9b58d1af9a0286162e52ef9db390d0c950fc1
>> Author: Thierry Reding 
>> Date:   Fri Mar 16 14:24:21 2018 +0100
>>
>> present: Advertise protocol version 1.2
>>
>> [...]
>>
>> Though I think the issue may lie in commit:
>>
>> commit 6a5d51e0823b43280e3646b7a0c919a3b76146ea
>> Author: Emil Velikov 
>> Date:   Mon Mar 19 16:04:43 2018 +
>>
>> present: cap the version returned to the client
>>
>> [...]
>>
>> I realise that Kwin will probably need to be modified to work with
>> Present 1.2, but I don't think we should be seeing breakage unti that
>> happens
>
> I think that's just exposing breakage somewhere else in the chain.
> With all these series applied, I've been able to get KDE to start with
> 'startkde' (running Plasma), both with new and old Mesa:
> https://patchwork.freedesktop.org/series/41104/
> https://patchwork.freedesktop.org/series/41106/
> https://patchwork.freedesktop.org/series/41142/
>
> Cheers,
> Daniel
___
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