Re: [PATCH xserver 0/2] Fix some error in Xorg.0.log

[Liwei Song]

On 04/13/2018 05:39 AM, Adam Jackson wrote:
> On Wed, 2018-04-11 at 22:49 -0400, Liwei Song wrote:
>> On my CoffeeLake S board, after compile i915 as a kernel module
>> will got following error in Xorg.0.log:
>> (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission 
>> denied
>> (EE) open /dev/fb0: No such file or directory
>>
>> This is a timing proble between i915 driver and Xorg,
>> add a loop to wait device got ready can avoid this timing problem
> 
> Ew. Why not delay starting your server until the device nodes exist?

Yes, This is a choice to avoid the error, but this way will change xserver
and i915 driver run in a serial mode, It may run 2 second slower than
parallel one, Although the time is very short.

And waiting in xserver won't impact the other board which did not suffer the 
error.
This way may make the whole xserver more flexible than add a precondition.
It may a little better than delay server.

Thanks,
Liwei.



> 'udevadm settle' perhaps?
> 
> - ajax
> 
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] xwayland: Don't crash on WarpPointer(dest_w = None)

[Peter Hutterer]

On Thu, Apr 12, 2018 at 05:24:08PM -0400, Adam Jackson wrote:
> Turns out that's legal, and xts exercises it, and we crash:
> 
> Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault.
> dixGetPrivate (key=0x813660 , privates=0x20) at 
> ../../include/privates.h:122
> 122   return (char *) (*privates) + key->offset;
> (gdb) bt
> #0  dixGetPrivate (key=0x813660 , privates=0x20) 
> at ../../include/privates.h:122
> #1  dixLookupPrivate (key=0x813660 , 
> privates=0x20) at ../../include/privates.h:166
> #2  xwl_window_of_top (window=0x0) at xwayland.c:128
> #3  xwl_cursor_warped_to (device=, screen=0x268b6e0, 
> client=, window=0x0, sprite=0x300bb30,
> x=2400, y=1350) at xwayland.c:292
> #4  0x005622ec in ProcWarpPointer (client=0x32755d0) at 
> events.c:3618
> 
> In this case, x/y are the screen-space coordinates where the pointer
> ends up, and we need to look up the (X) window there.
> 
> Signed-off-by: Adam Jackson 

Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> ---
>  hw/xwayland/xwayland.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
> index e65d8b7e77..dd074c3415 100644
> --- a/hw/xwayland/xwayland.c
> +++ b/hw/xwayland/xwayland.c
> @@ -289,6 +289,9 @@ xwl_cursor_warped_to(DeviceIntPtr device,
>  if (!xwl_seat)
>  xwl_seat = xwl_screen_get_default_seat(xwl_screen);
>  
> +if (!window)
> +window = XYToWindow(sprite, x, y);
> +
>  xwl_window = xwl_window_of_top(window);
>  if (!xwl_window && xwl_seat->focus_window) {
>  focus = xwl_seat->focus_window->window;
> -- 
> 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: [PATCH xserver 0/2] Fix some error in Xorg.0.log

[Adam Jackson]

On Wed, 2018-04-11 at 22:49 -0400, Liwei Song wrote:
> On my CoffeeLake S board, after compile i915 as a kernel module
> will got following error in Xorg.0.log:
> (EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission 
> denied
> (EE) open /dev/fb0: No such file or directory
> 
> This is a timing proble between i915 driver and Xorg,
> add a loop to wait device got ready can avoid this timing problem

Ew. Why not delay starting your server until the device nodes exist?
'udevadm settle' perhaps?

- 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] configure.ac: make use of wayland-scanner.pc

[Adam Jackson]

On Wed, 2018-04-11 at 18:51 +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Replace the current (incorrect) assumption that wayland-scanner is
> located in the wayland-client prefix. Make use of the wayland_scanner
> variable in wayland-scanner.pc
> 
> It was introduced back in 2013 and we already require newer wayland bits
> 
> Signed-off-by: Emil Velikov 

Merged (with fixup for new context), thanks:

remote: E: failed to find patch for rev 
d7269b49c3408f93a6cb8e28ddc3dda88224620a.
remote: I: 0 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   0031bbad84..d7269b49c3  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

[PATCH xserver] xwayland: Don't crash on WarpPointer(dest_w = None)

[Adam Jackson]

Turns out that's legal, and xts exercises it, and we crash:

Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault.
dixGetPrivate (key=0x813660 , privates=0x20) at 
../../include/privates.h:122
122 return (char *) (*privates) + key->offset;
(gdb) bt
#0  dixGetPrivate (key=0x813660 , privates=0x20) at 
../../include/privates.h:122
#1  dixLookupPrivate (key=0x813660 , privates=0x20) 
at ../../include/privates.h:166
#2  xwl_window_of_top (window=0x0) at xwayland.c:128
#3  xwl_cursor_warped_to (device=, screen=0x268b6e0, 
client=, window=0x0, sprite=0x300bb30,
x=2400, y=1350) at xwayland.c:292
#4  0x005622ec in ProcWarpPointer (client=0x32755d0) at 
events.c:3618

In this case, x/y are the screen-space coordinates where the pointer
ends up, and we need to look up the (X) window there.

Signed-off-by: Adam Jackson 
---
 hw/xwayland/xwayland.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index e65d8b7e77..dd074c3415 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -289,6 +289,9 @@ xwl_cursor_warped_to(DeviceIntPtr device,
 if (!xwl_seat)
 xwl_seat = xwl_screen_get_default_seat(xwl_screen);
 
+if (!window)
+window = XYToWindow(sprite, x, y);
+
 xwl_window = xwl_window_of_top(window);
 if (!xwl_window && xwl_seat->focus_window) {
 focus = xwl_seat->focus_window->window;
-- 
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: [PATCH app/xdpyinfo v3] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

[Adam Jackson]

On Thu, 2018-04-12 at 20:47 +0200, Pali Rohár wrote:
> XServer with enabled XRANDR 1.2 extension does not provide correct
> dimensions from DisplayWidthMM() and DisplayHeightMM() calls anymore.
> Values are calculated from fixed DPI 96.
> 
> Therefore when XRANDR 1.2 extension is enabled, present and user requested
> for it, instead use XRRGetScreenResources() and XRRGetOutputInfo() calls to
> get correct dimensions and resolution information.
> 
> Otherwise when XRANDR 1.2 extension is enabled, present and user did not
> request for it (which is default), show note that printed dimension does
> not have to be correct and instruct user to run xdpyinfo with -ext RANDR.

This should print the RANDR data in a separate stanza after the main
output, like the other extensions do. Again: the purpose of the core of
xdpyinfo is to tell you what the connection block says. Don't make it
print something else.

- 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 app/xdpyinfo v3] Use XRANDR 1.2 extension for reporting dimensions and resolution per output

[Pali Rohár]

XServer with enabled XRANDR 1.2 extension does not provide correct
dimensions from DisplayWidthMM() and DisplayHeightMM() calls anymore.
Values are calculated from fixed DPI 96.

Therefore when XRANDR 1.2 extension is enabled, present and user requested
for it, instead use XRRGetScreenResources() and XRRGetOutputInfo() calls to
get correct dimensions and resolution information.

Otherwise when XRANDR 1.2 extension is enabled, present and user did not
request for it (which is default), show note that printed dimension does
not have to be correct and instruct user to run xdpyinfo with -ext RANDR.

Also update manual page and add information that xdpyinfo does not provide
correct information about DPI.

Signed-off-by: Pali Rohár 
---
Changes since v2:
* Fixed dimensions calculation when rotation is active
* Show XRANDR output only when explicitly requested
* Update manpage

Changes since v1:
* Fixed detection of presence of XRANDR 1.2
* Fixed resolution calculation when dimensions are zero
---
 Makefile.am  |   2 +
 configure.ac |  12 ++
 man/xdpyinfo.man |   7 
 xdpyinfo.c   | 117 ++-
 4 files changed, 128 insertions(+), 10 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 2f21dda..496094e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -35,6 +35,7 @@ AM_CFLAGS = \
$(DPY_XCOMPOSITE_CFLAGS) \
$(DPY_XINERAMA_CFLAGS) \
$(DPY_DMX_CFLAGS) \
+   $(DPY_XRANDR_CFLAGS) \
$(DPY_XTST_CFLAGS)
 
 xdpyinfo_LDADD = \
@@ -49,6 +50,7 @@ xdpyinfo_LDADD = \
$(DPY_XCOMPOSITE_LIBS) \
$(DPY_XINERAMA_LIBS) \
$(DPY_DMX_LIBS) \
+   $(DPY_XRANDR_LIBS) \
$(DPY_XTST_LIBS)
 
 xdpyinfo_SOURCES = \
diff --git a/configure.ac b/configure.ac
index 73dce26..4473faa 100644
--- a/configure.ac
+++ b/configure.ac
@@ -132,6 +132,18 @@ else
echo "without dmx"
 fi
 
+AC_ARG_WITH(xrandr, AS_HELP_STRING([--without-xrandr],[Disable xrandr 1.2 
support.]),
+   [USE_XRANDR="$withval"], [USE_XRANDR="yes"])
+if test "x$USE_XRANDR" != "xno" ; then
+   PKG_CHECK_MODULES(DPY_XRANDR, xrandr >= 1.2,
+   [SAVE_CPPFLAGS="$CPPFLAGS"
+   CPPFLAGS="$CPPFLAGS $DPY_XRANDR_CFLAGS $DPY_X11_CFLAGS"
+   AC_CHECK_HEADERS([X11/extensions/Xrandr.h],,,[#include 
])
+   CPPFLAGS="$SAVE_CPPFLAGS"],[echo "not found"])
+else
+   echo "without xrandr 1.2"
+fi
+
 PKG_CHECK_MODULES(DPY_XTST, xtst,
[SAVE_CPPFLAGS="$CPPFLAGS"
CPPFLAGS="$CPPFLAGS $DPY_XTST_CFLAGS $DPY_X11_CFLAGS"
diff --git a/man/xdpyinfo.man b/man/xdpyinfo.man
index c3d5c6d..5df44ea 100644
--- a/man/xdpyinfo.man
+++ b/man/xdpyinfo.man
@@ -51,6 +51,13 @@ Detailed information about a particular extension is 
displayed with the
 \fBall\fP, information about all extensions supported by both \fIxdpyinfo\fP
 and the server is displayed.
 .PP
+Do not use this utility for determining dimensions of monitor when XRANDR 1.2+
+extension is enabled for X screen, because it does not provide them. For
+determining physical dimensions or DPI of particular monitor use either
+.IR xrandr (__appmansuffix__)
+utility or call xdpyinfo with parameter \fB\-ext RANDR\fP (supported since
+xdpyinfo version 1.3.3).
+.PP
 If \fB-version\fP is specified, xdpyinfo prints its version and exits, without
 contacting the X server.
 .SH ENVIRONMENT
diff --git a/xdpyinfo.c b/xdpyinfo.c
index 152e32c..ac2526f 100644
--- a/xdpyinfo.c
+++ b/xdpyinfo.c
@@ -76,6 +76,10 @@ in this Software without prior written authorization from 
The Open Group.
 #  define DMX
 # endif
 
+# if HAVE_X11_EXTENSIONS_XRANDR_H
+#  define XRANDR
+# endif
+
 #endif
 
 #ifdef WIN32
@@ -137,6 +141,9 @@ in this Software without prior written authorization from 
The Open Group.
 #ifdef DMX
 #include 
 #endif
+#ifdef XRANDR
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -442,6 +449,10 @@ print_visual_info(XVisualInfo *vip)
vip->bits_per_rgb);
 }
 
+#ifdef XRANDR
+static Bool print_xrandr = False;
+#endif
+
 static void
 print_screen_info(Display *dpy, int scr)
 {
@@ -455,6 +466,14 @@ print_screen_info(Display *dpy, int scr)
 double xres, yres;
 int ndepths = 0, *depths = NULL;
 unsigned int width, height;
+Bool has_xrandr = False;
+#ifdef XRANDR
+int event_base, error_base;
+int major, minor;
+XRRScreenResources *res;
+XRROutputInfo *output;
+XRRCrtcInfo *crtc;
+#endif
 
 /*
  * there are 2.54 centimeters to an inch; so there are 25.4 millimeters.
@@ -464,18 +483,81 @@ print_screen_info(Display *dpy, int scr)
  * = N * 25.4 pixels / M inch
  */
 
-xres = double) DisplayWidth(dpy,scr)) * 25.4) /
-   ((double) DisplayWidthMM(dpy,scr)));
-yres = double) DisplayHeight(dpy,scr)) * 25.4) /
-   ((double) DisplayHeightMM(dpy,scr)));
-
 printf ("\n");
 printf ("screen #%d:\n", scr);
-printf ("  dimensions:

[PATCH app/xrandr] Fix checking for valid argument of --dpi

[Pali Rohár]

Function strtod() sets strtod_error to the pointer of the first invalid
character and therefore it does not have to be first character from input.
When input is valid then it points to nul byte. Conversion error is
indicated by setted errno. Zero-length argument and zero DPI is invalid
too.

Update also error message about invalid argument.

Signed-off-by: Pali Rohár 
---
 xrandr.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/xrandr.c b/xrandr.c
index 7f1e867..1960bbf 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -3115,9 +3115,10 @@ main (int argc, char **argv)
}
if (!strcmp ("--dpi", argv[i])) {
char *strtod_error;
-   if (++i >= argc) argerr ("%s requires an argument\n", argv[i-1]);
+   if (++i >= argc || !argv[i][0]) argerr ("%s requires an 
argument\n", argv[i-1]);
+   errno = 0;
dpi = strtod(argv[i], _error);
-   if (argv[i] == strtod_error)
+   if (*strtod_error || errno || dpi == 0)
{
dpi = 0.0;
dpi_output_name = argv[i];
@@ -3567,7 +3568,7 @@ main (int argc, char **argv)
XRROutputInfo   *output_info;
XRRModeInfo *mode_info;
if (!dpi_output)
-   fatal ("Cannot find output %s\n", dpi_output_name);
+   fatal ("%s is not valid DPI nor valid output\n", 
dpi_output_name);
output_info = dpi_output->output_info;
mode_info = dpi_output->mode_info;
if (output_info && mode_info && output_info->mm_height)
-- 
2.11.0

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

Re: X-window crashes

[Adam Jackson]

On Wed, 2018-04-11 at 13:12 -0700, Alan Coopersmith wrote:
> On 04/10/18 01:52 PM, alexander@wellsfargo.com wrote:
> > 
> > flexSA14523.log:The program 'flextrdr_gtk' received an X Window System 
> > error.
> > 
> > flexSA14523.log-This probably reflects a bug in the program.
> > 
> > flexSA14523.log-The error was 'BadLength (poly request too large or internal
> > Xlib length erro'.
> > 
> > flexSA14523.log-  (Details: serial 28147239 error_code 16 request_code 32
> > minor_code 0)
> 
> Basically it's telling you there's a bug in flextrdr_gtk in which it's
> doing something that results in a call to UngrabKeyboard with an
> invalid argument.  That's likely to be a call from your program to
> something in the gtk toolkit that in turn makes that call.

BadLength though? If it was an invalid argument you'd get BadValue. And
UngrabKeyboard is a fixed-length request, we're never going to put it
on the wire with the wrong length if you call XUngrabKeyboard(). I'd
suspect that the _previous_ request had a bad length, shorter than the
data actually written, and the data at the end is misinterpreted as a
(malformed) UngrabKeyboard request.

It would be interesting to use xscope or wireshark or whatever to see
what the last requests written are.

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

Re: [PATCH xserver] sdksyms: Skip empty symbols

[Jeff Smith]

> my awk skills are non-existent but shouldn't this be $symbol? The condition a 
> few
> lines above uses $n == "" instead of n == ""
>
> with that change, Reviewed-by: Peter Hutterer 
>
> Cheers,
>Peter

Well, awk is a bit peculiar in that respect.
Noting that awk automatically splits a read line into tokens $1, $2,
$3, and so on (and $0 is the whole),
where n == 2, $n would be equal to the second token of the
most-recently read line.

"symbol" without the dollar sign is actually correct.

 - Jeff
___
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] randr: Do not crash if slave screen does not have provider.

[Michal Srb]

All GPU screens are attached as unbound GPUs to master, even if they have no
capabilities or the provider field is null. Handle that case in RRTellChanged.
---
This prevents crash in setups with for example two qxl devices, or fbdev and
qxl device. I am not sure if it is a proper fix and not just papering over a
bug somewhere else, but there are more places that test whether the provider
is set, so maybe it is correct way.

I would think that if a slave screen does not have provider, there is no reason
for it to become an unbound GPU in master's slave_list. Similarly if master has
no provider, then having anything in slave_list is useless. But it seems the
AttachUnboundGPU and the rest of the code handling screen to GPU screen
attachments does not know about randr's privates, so it can not check whether
provider is there.

 randr/randr.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/randr/randr.c b/randr/randr.c
index feb54bcc8..661f66da2 100644
--- a/randr/randr.c
+++ b/randr/randr.c
@@ -643,7 +643,9 @@ RRTellChanged(ScreenPtr pScreen)
 
 xorg_list_for_each_entry(iter, >slave_list, slave_head) {
 pSlaveScrPriv = rrGetScrPriv(iter);
-pSlaveScrPriv->provider->changed = FALSE;
+if (pSlaveScrPriv->provider) {
+pSlaveScrPriv->provider->changed = FALSE;
+}
 if (iter->is_output_slave) {
 for (i = 0; i < pSlaveScrPriv->numOutputs; i++)
 pSlaveScrPriv->outputs[i]->changed = FALSE;
-- 
2.13.6

___
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

[Mike Lothian]

Hi

Sending this again with the attachements compressed

I've done some more testing. The flashing I was seeing with Xserver 1.19.5
goes away when I use egl rather then glx with Kwin - I won't be using egl
in any of the next tests

When I use Xserver 1.20 RC4 with Intel/AMDPGU DDXs Kwin doesn't start - the
X server is running (I'm attaching logs) - that's the case whether
compositing is enabled or not in Kwin

With the modesetting driver, Kwin launches with compositing enabled or
disabled. However the lockups in plasmashell are still present. These
happen with compositing enabled or disabled too. Simplest way to reproduce
- press the start button multiple times until it locks up (usually within 4
times) - leaving it overnight, it seems to have unlocked itself.
Alternatively "killall -9 plasmashell && sleep 1 && plasmashell" sorts it
from "Alt + F2". I've attached the journal again just after a freeze
(journalctl.freeze)

Cheers

Mike

On Mon, 9 Apr 2018 at 11:07 Mike Lothian  wrote:

> Switching between egl and glx can only be done these days by editing the
> kwinrc file (egl however is used by default on wayland I believe), egl was
> still enabled from years ago when switching was easy
>
> I've attached some coredumps on the bug, though I don't have any debugging
> compiled into the binaries so I'm not sure how useful they are
>
> On Mon, 9 Apr 2018 at 10:45 Roman Gilg  wrote:
>
>> On Sat, Apr 7, 2018 at 9:56 AM, Mike Lothian  wrote:
>> > Switching to glx from egl gets things started for me
>>
>> Do you mean switching from egl to glx as in switching the compositing
>> backend? And it did not work with egl backend but with glx?
>>
>> The egl backend on X in KWin isn't supported well at the moment and
>> switching between them shouldn't be possible anymore from the control
>> module in system settings.
>>
>> Can you post a backtrace from the dying process? Is it KWin or
>> Plasmashell? The one of Plasmashell in the Gentoo bug report is with
>> an AMD card.
>>
>> Cheers
>> Roman
>>
>


Xorg.0.log.xz
Description: application/xz


journalctl.xz
Description: application/xz


dmesg.xz
Description: application/xz


journalctl.freeze.xz
Description: application/xz
___
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] sdksyms: Skip empty symbols

[Thomas Klausner]

On Wed, Apr 11, 2018 at 03:39:33PM -0400, Adam Jackson wrote:
> Apparently on NetBSD we can hit failures like this:
> 
> sdksyms.c:1773:15: error: expected expression before ',' token
>  (void *) &,  /* 
> ../../dri3/dri3.h:110 */
> 
> I've been unable to reproduce that locally (even in a NetBSD vm), but
> an obvious workaround might be to just notice empty symbol names and
> ignore them rather than emit invalid C code.
> 
> Cc: Thomas Klausner 
> Signed-off-by: Adam Jackson 
> ---
>  hw/xfree86/sdksyms.sh | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

That patch fixes the problem for me, thank you!

I had another local change to the file, it doesn't look related but
perhaps it is; full patch attached.

Looking at the package, I have more changes that are not integrated,
I'll prepare a changeset later.

Thanks,
 Thomas


patch-hw_xfree86_sdksyms.sh
Description: Bourne shell script
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [ANNOUNCE] xorg-server 1.19.99.904

[Thomas Klausner]

On Wed, Apr 11, 2018 at 04:24:02PM -0500, Jeff Smith wrote:
> On Wed, Apr 11, 2018 at 2:44 AM, Thomas Klausner  wrote:
> > I still see this build failure on NetBSD:
> >
> > sdksyms.c:1773:15: error: expected expression before ',' token
> >  (void *) &,  /* 
> > ../../dri3/dri3.h:110 */
> >^
> >
> >  Thomas
> >
> 
> BTW, because of a line-numbering bug in sdksyms.sh, it is misreporting
> the relevant header line as dri3.h:110,
> when it should have reported dri3.h:113 (the line declaring
> drm_format_for_depth).  I'm limited in what I can
> test at the moment, and haven't been able to reproduce or see a reason
> why that line would be a problem.

True, there seems to be a line numbering bug:

(void *) _screen_init,  /* 
../../dri3/dri3.h:106 */
(void *) _send_open_reply,  /* 
../../dri3/dri3.h:108 */
(void *) &,  /* 
../../dri3/dri3.h:110 */

and in dri3/dri3.h:

   106  extern _X_EXPORT Bool
   107  dri3_screen_init(ScreenPtr screen, const dri3_screen_info_rec *info);
   108  
   109  extern _X_EXPORT int
   110  dri3_send_open_reply(ClientPtr client, int fd);
   111  
   112  extern _X_EXPORT uint32_t
   113  drm_format_for_depth(uint32_t depth, uint32_t bpp);

> I wonder, is that the only line in sdksyms.c that came out like that,
> or just the first?

It's the only one.
 Thomas
___
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