[PATCH xserver 1/2] config: wait for DRM device to be successful initiated

[Liwei Song]

On my CoffeeLake machine, when build i915 driver as kernel module,
will got following error message in Xorg.0.log:
(EE) /dev/dri/card0: failed to set DRM interface version 1.4: Permission denied

When compile i915 as kernel module, drm device won't be initiated
after rootfs was mounted. This may led Xorg access DRM device failed,
since DRM  was not successful created by i915 driver yet.
Then the set version process will not be done in InitOutput(),
and it will be delayed to InitInput(), when came into InitInput()
DRM device already maped to memory, So through ioctl set DRM interface
version will failed, then print the error message in Xorg.0.log.

To avoid the timing problem between i915.ko and Xorg,  we need make
sure DRM device was created and no process hold it, because nobody
hold it in InitOutput(), then the rest work is to ensure DRM was
created successful. So add a loop method to wait DRM device are
available.

Signed-off-by: Liwei Song 
---
 config/udev.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/config/udev.c b/config/udev.c
index 3a73189e2558..2398603cd87b 100644
--- a/config/udev.c
+++ b/config/udev.c
@@ -486,8 +486,11 @@ config_udev_odev_probe(config_odev_probe_proc_ptr 
probe_callback)
 struct udev *udev;
 struct udev_enumerate *enumerate;
 struct udev_list_entry *devices, *device;
+int loop = 0;
 
 udev = udev_monitor_get_udev(udev_monitor);
+
+retry:
 enumerate = udev_enumerate_new(udev);
 if (!enumerate)
 return;
@@ -500,6 +503,12 @@ config_udev_odev_probe(config_odev_probe_proc_ptr 
probe_callback)
 #endif
 udev_enumerate_scan_devices(enumerate);
 devices = udev_enumerate_get_list_entry(enumerate);
+if (!devices && loop++ <= 10){
+   usleep(10);
+   udev_enumerate_unref(enumerate);
+   goto retry;
+}
+
 udev_list_entry_foreach(device, devices) {
 const char *syspath = udev_list_entry_get_name(device);
 struct udev_device *udev_device = udev_device_new_from_syspath(udev, 
syspath);
-- 
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] sdksyms: Skip empty symbols

[Peter Hutterer]

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(-)
> 
> diff --git a/hw/xfree86/sdksyms.sh b/hw/xfree86/sdksyms.sh
> index d927fcd165..fc171d9188 100755
> --- a/hw/xfree86/sdksyms.sh
> +++ b/hw/xfree86/sdksyms.sh
> @@ -415,7 +415,8 @@ BEGIN {
>   sub(/[^a-zA-Z0-9_].*/, "", symbol);
>  
>   #print;
> - printf("(void *) &%-50s /* %s:%s */\n", symbol ",", header, line);
> + if (symbol != "")

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

> + printf("(void *) &%-50s /* %s:%s */\n", symbol ",", header, 
> line);
>  }
>  }
>  
> -- 
> 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 0/2] Fix some error in Xorg.0.log

[Liwei Song]

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


Liwei Song (2):
  config: wait for DRM device to be successful initiated
  fbdevhw: add loop to wait /dev/fb0 get ready

 config/udev.c| 9 +
 hw/xfree86/fbdevhw/fbdevhw.c | 4 +++-
 2 files changed, 12 insertions(+), 1 deletion(-)

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

[PATCH xserver 2/2] fbdevhw: add loop to wait /dev/fb0 get ready

[Liwei Song]

After compile i915 driver as kernel module, will got error message:
(EE) open /dev/fb0: No such file or directory

This is because i915 driver did not finish fb initialized work
while process trying to open it. This is still a timing problem between
i915.ko and Xorg

Add a loop to wait i915 driver finished its initialize work
can fix this error.

Signed-off-by: Liwei Song 
---
 hw/xfree86/fbdevhw/fbdevhw.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/fbdevhw/fbdevhw.c b/hw/xfree86/fbdevhw/fbdevhw.c
index 0bd77df87e04..adca43809b59 100644
--- a/hw/xfree86/fbdevhw/fbdevhw.c
+++ b/hw/xfree86/fbdevhw/fbdevhw.c
@@ -309,6 +309,7 @@ fbdev_open(int scrnIndex, const char *dev, char **namep)
 {
 struct fb_fix_screeninfo fix;
 int fd;
+int loop = 0;
 
 /* try argument (from XF86Config) first */
 if (dev) {
@@ -320,7 +321,8 @@ fbdev_open(int scrnIndex, const char *dev, char **namep)
 if ((NULL == dev) || ((fd = open(dev, O_RDWR, 0)) == -1)) {
 /* last try: default device */
 dev = "/dev/fb0";
-fd = open(dev, O_RDWR, 0);
+while ((fd = open(dev, O_RDWR, 0)) == -1 && loop++ <= 100)
+   usleep(2);
 }
 }
 
-- 
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: Bug 105851 Xserver 1.20 RC2+ issues with Kwin + Present 1.2

[Mike Lothian]

I'm wondering if it's this commit that added it back in January

commit 7617a0a180a2cd3427a8ffa9534152df6a8fecbf
Author: Qiang Yu 
Date:   Wed Jan 11 13:59:22 2017 +0800

   dri2: refine dri2_probe_driver_name (v2)

   V2:
   1. update comment
   2. check bustype if PCI
   3. configure add libdrm version check for drmGetDevice

   Get PCI information from info->fd with drmGetDevice instead of
   assuming the info->fd is the first entity of scrn which is not
   true for multi entities scrn.

   Signed-off-by: Qiang Yu 
   Reviewed-by: Emil Velikov 

On 11 April 2018 at 23:11, Mike Lothian  wrote:
> I've also noticed the AMDGPU powers up each time I play a video -
> either using SMplayer or on Chromium
>
> [50458.810260] snd_hda_codec_ca0132 hdaudioC0D0: ca0132 DSP downloaded
> and running
> [50459.699224] [drm] PCIE GART of 1024M enabled (table at 0x00F4).
> [50459.797265] [drm] UVD initialized successfully.
> [50460.008408] [drm] VCE initialized successfully.
> [50465.175833] amdgpu :01:00.0: GPU pci config reset
>
> I used to see this before the drmDevice2 (my memory is a bit fuzzy)
> stuff landed, so the device wouldn't power up when the device node was
> probed
>
> On 11 April 2018 at 22:53, Mike Lothian  wrote:
>> The journal.freeze I mentioned but was too big to attach
>>
>> On 11 April 2018 at 22:53, Mike Lothian  wrote:
>>> Hi
>>>
>>> Hopefully 3rd time lucky (sorry Roman)
>>>
>>> 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 in the next email)
>>>
>>> Cheers
>>>
>>> Mike
___
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]

I've also noticed the AMDGPU powers up each time I play a video -
either using SMplayer or on Chromium

[50458.810260] snd_hda_codec_ca0132 hdaudioC0D0: ca0132 DSP downloaded
and running
[50459.699224] [drm] PCIE GART of 1024M enabled (table at 0x00F4).
[50459.797265] [drm] UVD initialized successfully.
[50460.008408] [drm] VCE initialized successfully.
[50465.175833] amdgpu :01:00.0: GPU pci config reset

I used to see this before the drmDevice2 (my memory is a bit fuzzy)
stuff landed, so the device wouldn't power up when the device node was
probed

On 11 April 2018 at 22:53, Mike Lothian  wrote:
> The journal.freeze I mentioned but was too big to attach
>
> On 11 April 2018 at 22:53, Mike Lothian  wrote:
>> Hi
>>
>> Hopefully 3rd time lucky (sorry Roman)
>>
>> 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 in the next email)
>>
>> Cheers
>>
>> Mike
___
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]

The journal.freeze I mentioned but was too big to attach

On 11 April 2018 at 22:53, Mike Lothian  wrote:
> Hi
>
> Hopefully 3rd time lucky (sorry Roman)
>
> 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 in the next email)
>
> Cheers
>
> Mike


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

[Mike Lothian]

Hi

Hopefully 3rd time lucky (sorry Roman)

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 in the next email)

Cheers

Mike


journalctl.xz
Description: application/xz


dmesg.xz
Description: application/xz


Xorg.0.log.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: [ANNOUNCE] xorg-server 1.19.99.904

[Jeff Smith]

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.

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

 - 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

Re: X-window crashes

[Alan Coopersmith]

On 04/10/18 01:52 PM, alexander@wellsfargo.com wrote:
> I have been scouring every knowledgebase available to me including exceed/open
> text resource to figure out why my application is crashing.  I basically use
> exceed to export the display to my windows pc.  So far this week, I had 5
> crashes.  Wondering if anyone knows or have dealt with this in the past?
> 
>  
> 
> 04/10/2018
> 
>  
> 
> 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.

-- 
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/alanc
___
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

X-window crashes

[Alexander.Tam]

I have been scouring every knowledgebase available to me including exceed/open 
text resource to figure out why my application is crashing.  I basically use 
exceed to export the display to my windows pc.  So far this week, I had 5 
crashes.  Wondering if anyone knows or have dealt with this in the past?

04/10/2018

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)
flexSA14523.log-  (Note to programmers: normally, X errors are reported 
asynchronously;
flexSA14523.log-   that is, you will receive the error a while after causing it.
flexSA14523.log-   To debug your program, run it with the --sync command line
flexSA14523.log-   option to change this behavior. You can then get a meaningful
flexSA14523.log-   backtrace from your debugger if you break on the 
gdk_x_error() function.)
flexSA14523.log-[13:58:16.163836] - **ERROR**   :FtDialog::~FtDialog(): 
destructor called when m_dialog is NULL
--
flexSA21884.log:The program 'flextrdr_gtk' received an X Window System error.
flexSA21884.log-This probably reflects a bug in the program.
flexSA21884.log-The error was 'BadLength (poly request too large or internal 
Xlib length erro'.
flexSA21884.log-  (Details: serial 7177316 error_code 16 request_code 32 
minor_code 0)
flexSA21884.log-  (Note to programmers: normally, X errors are reported 
asynchronously;
flexSA21884.log-   that is, you will receive the error a while after causing it.
flexSA21884.log-   To debug your program, run it with the --sync command line
flexSA21884.log-   option to change this behavior. You can then get a meaningful
flexSA21884.log-   backtrace from your debugger if you break on the 
gdk_x_error() function.)
flexSA21884.log-[11:16:46.093565] - **ERROR**   :FtDialog::~FtDialog(): 
destructor called when m_dialog is NULL
--
flexSA21993.log:The program 'flextrdr_gtk' received an X Window System error.
flexSA21993.log-This probably reflects a bug in the program.
flexSA21993.log-The error was 'BadLength (poly request too large or internal 
Xlib length erro'.
flexSA21993.log-  (Details: serial 16919110 error_code 16 request_code 1 
minor_code 0)
flexSA21993.log-  (Note to programmers: normally, X errors are reported 
asynchronously;
flexSA21993.log-   that is, you will receive the error a while after causing it.
flexSA21993.log-   To debug your program, run it with the --sync command line
flexSA21993.log-   option to change this behavior. You can then get a meaningful
flexSA21993.log-   backtrace from your debugger if you break on the 
gdk_x_error() function.)
flexSA21993.log-[15:05:10.120525] - **ERROR**   :FtDialog::~FtDialog(): 
destructor called when m_dialog is NULL

04/09/2018

flexSA28811.log:The program 'flextrdr_gtk' received an X Window System error.
flexSA28811.log-This probably reflects a bug in the program.
flexSA28811.log-The error was '156'.
flexSA28811.log-  (Details: serial 9773998 error_code 156 request_code 144 
minor_code 5)
flexSA28811.log-  (Note to programmers: normally, X errors are reported 
asynchronously;
flexSA28811.log-   that is, you will receive the error a while after causing it.
flexSA28811.log-   To debug your program, run it with the --sync command line
flexSA28811.log-   option to change this behavior. You can then get a meaningful
flexSA28811.log-   backtrace from your debugger if you break on the 
gdk_x_error() function.)
flexSA28811.log-[10:42:57.150157] - **ERROR**   :FtDialog::~FtDialog(): 
destructor called when m_dialog is NULL

flexSA12824.log:The program 'flextrdr_gtk' received an X Window System error.
flexSA12824.log-This probably reflects a bug in the program.
flexSA12824.log-The error was 'BadLength (poly request too large or internal 
Xlib length erro'.
flexSA12824.log-  (Details: serial 26306665 error_code 16 request_code 32 
minor_code 0)
flexSA12824.log-  (Note to programmers: normally, X errors are reported 
asynchronously;
flexSA12824.log-   that is, you will receive the error a while after causing it.
flexSA12824.log-   To debug your program, run it with the --sync command line
flexSA12824.log-   option to change this behavior. You can then get a meaningful
flexSA12824.log-   backtrace from your debugger if you break on the 
gdk_x_error() function.)
flexSA12824.log-[14:30:46.048814] - **ERROR**   :FtDialog::~FtDialog(): 
destructor called when m_dialog is NULL

not sure what the error means.  Please help.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[PATCH xserver] sdksyms: Skip empty symbols

[Adam Jackson]

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

diff --git a/hw/xfree86/sdksyms.sh b/hw/xfree86/sdksyms.sh
index d927fcd165..fc171d9188 100755
--- a/hw/xfree86/sdksyms.sh
+++ b/hw/xfree86/sdksyms.sh
@@ -415,7 +415,8 @@ BEGIN {
sub(/[^a-zA-Z0-9_].*/, "", symbol);
 
#print;
-   printf("(void *) &%-50s /* %s:%s */\n", symbol ",", header, line);
+   if (symbol != "")
+   printf("(void *) &%-50s /* %s:%s */\n", symbol ",", header, 
line);
 }
 }
 
-- 
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] configure.ac: make use of wayland-scanner.pc

[Emil Velikov]

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 
---
More or less the same patch has been part of weston and mesa for a few
years now.
---
 configure.ac | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 828d15e95..a851cc369 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2387,9 +2387,11 @@ if test "x$XWAYLAND" = xyes; then
AC_MSG_ERROR([Xwayland requires CLOCK_MONOTONIC support.])
fi
 
-   WAYLAND_PREFIX=`$PKG_CONFIG --variable=prefix wayland-client`
-   AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner],,
-[${WAYLAND_PREFIX}/bin$PATH_SEPARATOR$PATH])
+   AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner])
+   if test "x$WAYLAND_SCANNER" = x; then
+   PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
+   AC_SUBST(WAYLAND_SCANNER, `$PKG_CONFIG 
--variable=wayland_scanner wayland-scanner`)
+   fi
 
AC_SUBST(WAYLAND_PROTOCOLS_DATADIR, `$PKG_CONFIG --variable=pkgdatadir 
wayland-protocols`)
 fi
-- 
2.16.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: Unsupported locale errors in XOrg

[Prashanth Chandra]

Ilya,

1.
/usr/share/X11/locale/locale.dir
does contain the line
en_US.UTF-8/XLC_LOCALE: en_HK.UTF-8
2.
/usr/share/X11/locale/locale.alias
doesn't contain a line beginning with
en_HK.UTF-8:
does contain lines beginning with
en_HK.utf8, en_HK.iso88591, etc.
3.
/etc/locale.gen
is fully commented except for the following two uncommented lines:
en_HK.UTF-8 UTF-8
en_US.UTF-8 UTF-8
4.
/etc/locale.alias
doesn't contain the string en_HK.UTF-8
5.
Then, I ran sudo update-locale LANG="en_HK.utf-8" LANGUAGE="en_HK" and rebooted
my locale was changed to the following:
LANG=en_HK.utf-8
LANGUAGE=en_HK
LC_CTYPE="en_HK.utf-8"
LC_NUMERIC="en_HK.utf-8"
LC_TIME="en_HK.utf-8"
LC_COLLATE="en_HK.utf-8"
LC_MONETARY="en_HK.utf-8"
LC_MESSAGES="en_HK.utf-8"
LC_PAPER="en_HK.utf-8"
LC_NAME="en_HK.utf-8"
LC_ADDRESS="en_HK.utf-8"
LC_TELEPHONE="en_HK.utf-8"
LC_MEASUREMENT="en_HK.utf-8"
LC_IDENTIFICATION="en_HK.utf-8"
LC_ALL=
But I'm still seeing the same errors.
6.
I don't know if this means anything, but I can't find any locales
starting with en_HK under /usr/share/X11/locale,
though I do see en_US.UTF-8.


Thomas,

That was the closest thread I found that matches my issue, though I'm
quite confident the root cause is entirely different.
I've seen this error for the first time a few years back and every
time I boot into a new install of Ubuntu desktop (the installer
detects IP country and uses it to set the locale),
though I've always ignored it and forced the default locale to en_US.UTF-8.

On Tue, Apr 10, 2018 at 4:08 PM, Thomas Lübking  wrote:
> On Tue, Apr 10, 2018 at 02:17:13AM +0800, Prashanth Chandra wrote:
>>
>> Hello,
>>
>> I'm getting "unsupported locale" warnings and crashes when running
>> programs such as xterm or dmenu on a clean install of Ubuntu 17.10
>>
>> Examples:
>> warning: no locale support
>> Warning: locale not supported by Xlib, locale set to C
>>
>> Here's the offending line from dmenu's source code:
>>
>> if (!setlocale(LC_CTYPE, "") || !XSupportsLocale())
>> fputs("warning: no locale support\n", stderr);
>
>
> You certainly have bleachbit installed ...?
>
> https://bbs.archlinux.org/viewtopic.php?pid=1669411#p1669411
>
>
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [ANNOUNCE] xorg-server 1.19.99.904

[Adam Jackson]

On Wed, 2018-04-11 at 09:44 +0200, 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 */
>^

I'm setting up a netbsd vm to look into this; debugging awk over email
sounded unpleasant.

- 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: [ANNOUNCE] xorg-server 1.19.99.904

[Olivier Fourdan]

Hey Adam,

On Wed, Apr 11, 2018 at 4:40 PM, Adam Jackson  wrote:

> On Wed, 2018-04-11 at 09:49 +0200, Olivier Fourdan wrote:
>
> > What are the risks of landing it? It would break for hardware/driver
> > which are not supported yet anyway?
>
> The code it adds basically only runs on NVIDIA's drivers, since nobody
> else supports EGL_KHR_streams (as far as I'm aware, at least). Mesa
> doesn't seem to have any interest in adding it, and even if they did
> we'd probably prefer to keep using gbm there as the streams approach is
> intrinsically one more blit, at least as written.
>
> So the risks are low. The benefit is Xwayland could use glamor instead
> of fb. Which you'd think would be a win, as I'm told NVIDIA's GL is
> pretty good. In practice it's kind of a wash at the moment. It's
> possible that's because glamor is doing something naive in its renderer
> or its streams usage, or due to a bug in NVIDIA's driver.
>

Right, and in the worse case (i.e. a bug with EGLstream crashes glamor),
users can set XWAYLAND_NO_GLAMOR to disable glamor support.

So the risks are even lower...

Cheers,
Olivier
___
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

[Adam Jackson]

On Wed, 2018-04-11 at 09:49 +0200, Olivier Fourdan wrote:

> What are the risks of landing it? It would break for hardware/driver
> which are not supported yet anyway?

The code it adds basically only runs on NVIDIA's drivers, since nobody
else supports EGL_KHR_streams (as far as I'm aware, at least). Mesa
doesn't seem to have any interest in adding it, and even if they did
we'd probably prefer to keep using gbm there as the streams approach is
intrinsically one more blit, at least as written.

So the risks are low. The benefit is Xwayland could use glamor instead
of fb. Which you'd think would be a win, as I'm told NVIDIA's GL is
pretty good. In practice it's kind of a wash at the moment. It's
possible that's because glamor is doing something naive in its renderer
or its streams usage, or due to a bug in NVIDIA's driver.

- 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: [ANNOUNCE] xorg-server 1.19.99.904

[Lucio]

Adam Jackson wrote:
> the deafening silence of review feedback has not been encouraging.

I've just subscribed to this list only to give my feedback about 
EGLStreams into XWayland, but I can't give any real review, only opinions.


I don't know what the policies are, but I feel like including EGLStreams 
is a way to endorse NVidia proprietary drivers.


If NVidia is really interested in having their drivers work with 
Wayland, they could contribute more to the Unix device memory allocation 
API. If they aren't interested, why should we bother?


I know, including EGLStreams speeds up Wayland adoption, but it slows 
down free software adoption.


It's not like Wayland is a forced choice: who wants/needs to use the 
NVidia proprietary driver can still do so using classic X. I fail to see 
use cases where users are forced both to use both Wayland and the NVidia 
proprietary drivers, so I think it's a good time to let users know what 
free software is supposed to be.


I hope I'm not too off topic with my opinion.

Thanks anyway for the good work.


___
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: [ANNOUNCE] xorg-server 1.19.99.904

[Olivier Fourdan]

Hi Adam,

[Re-sending to xorg-devel where this was intended, sorry!]

On 10 April 2018 at 21:57, Adam Jackson  wrote:

> Another batch of cleanups and fixes, mostly in glamor and DRI3.
>
> At this point the only outstanding major feature for 1.20 that hasn't
> landed yet is EGLStreams support for Xwayland. The patches require some
> minor rebasing to account for per-window flips in Present, I'll post
> that momentarily I suppose. I'm honestly of two minds about merging it,
> the deafening silence of review feedback has not been encouraging.
>

FWIW, I actually looked at the patches and did not spot anything wrong at
the time, but I don't have any hardware/driver to actually try it, so I
cannot tell whether or not those are correct, so I did not reply...

What are the risks of landing it? It would break for hardware/driver which
are not supported yet anyway?

Cheers,
Olivier
___
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

how to get button press event on window manager ?

[????]

Hi all.I would like to be able to raise the clicked window to the top of the 
stack on my window manager. But it fail because only one client can SelectInput 
on Button events at one time. How can I realize my goal? Here is my code :

#include 
int main(void)
{
Display *display=XOpenDisplay(NULL);
XSelectInput(display, DefaultRootWindow(display), 
SubstructureRedirectMask|SubstructureNotifyMask|ButtonPressMask|OwnerGrabButtonMask);
XEvent event;
while(1)
{
XNextEvent(display, );
switch(event.type)
{
case ButtonPress :
XRaiseWindow(display, event.xbutton.window);
XSetInputFocus(display, event.xbutton.window, 
RevertToPointerRoot, CurrentTime);
break;
case ConfigureRequest :
/* ... */
break;
case MapRequest :
XMapWindow(display, event.xmaprequest.window);
break;
}
}
return 0;
}___
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: [ANNOUNCE] xorg-server 1.19.99.904

[Thomas Klausner]

I still see this build failure on NetBSD:

sdksyms.c:1773:15: error: expected expression before ',' token
 (void *) &,  /* 
../../dri3/dri3.h:110 */
   ^

 Thomas

On Tue, Apr 10, 2018 at 03:57:25PM -0400, Adam Jackson wrote:
> Another batch of cleanups and fixes, mostly in glamor and DRI3.
> 
> At this point the only outstanding major feature for 1.20 that hasn't
> landed yet is EGLStreams support for Xwayland. The patches require some
> minor rebasing to account for per-window flips in Present, I'll post
> that momentarily I suppose. I'm honestly of two minds about merging it,
> the deafening silence of review feedback has not been encouraging.
> 
> Aaron Plattner (1):
>   xfree86: Restore newline before "X Protocol Version" string
> 
> Adam Jackson (10):
>   gtf: Warning fix
>   dmx: Fix some snprintf warnings.
>   dmx: Fix a read-from-uninitialized warning
>   dmx: Clean up some argument parsing code
>   dmx: Silence a string truncation warning.
>   xkb: Silence some compiler warnings
>   mi: Hush an almost certainly bogus warning
>   dix: Hush an almost certainly bogus warning
>   xwayland: Silence a build warning if we can
>   xserver 1.20 RC4
> 
> Daniel Stone (10):
>   dri3: Use single-FD screen call for single-FD request
>   drmmode: Track if BO allocation used modifiers
>   glamor: Track if BO allocation used modifiers
>   glamor: Push make_exportable into callers
>   glamor: Reallocate pixmap storage without modifiers if necessary
>   glamor: Fall back to non-modifier allocations
>   glamor: Add fd_from_pixmap hook
>   modesetting: Don't reuse iterator in nested loop
>   dri3: Set stride and size for old clients
>   modesetting: Actually get framebuffer ID
> 
> Emil Velikov (10):
>   dri3: annotate the dri3_screen_info data as const
>   xwayland: don't close() fds we don't own
>   dri3: annotate fds/strides/offsets arrays as const
>   dri3: simplify dri3_open() implementation
>   xwayland: zero num_modifiers from the start
>   glamor: zero num_modifiers from the start
>   dri3: check for ::get_drawable_modifiers failure
>   xwayland: zero num_formats from the start
>   glamor: zero num_formats from the start
>   dri3: rework format/modifier caching
> 
> Jon Turney (1):
>   hw/xwin/glx: Allocate fbconfigs correctly
> 
> Kyle Brenneman (1):
>   GLX: Fix a use after free error with the GLVND vendor handle.
> 
> Louis-Francis Ratté-Boulianne (2):
>   modesetting: Use atomic modesetting to set DPMS mode
>   modesetting: Have consistent state when using atomic modesetting
> 
> Mario Kleiner (1):
>   modesetting: Fix page flipping harder under DRI 3.2.
> 
> Michal Srb (2):
>   glx: Do not call into Composite if it is disabled.
>   Xext: Fix memory leaks in hashtable.
> 
> Peter Hutterer (1):
>   xfree86: drop KDSKBMUTE handling
> 
> Samuel Thibault (1):
>   dix: always send focus event on grab change
> 
> git tag: xorg-server-1.19.99.904
> 
> https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.904.tar.bz2
> MD5:  b7623726287e405ed03b9e27f0811f87  xorg-server-1.19.99.904.tar.bz2
> SHA1: 5bfe19ab814ab8b973c0c4b53547de4e951d3679  
> xorg-server-1.19.99.904.tar.bz2
> SHA256: 0ec3bb260c3798964d413db4238485fca5cab774a9d279c04e5272202f8e58b8  
> xorg-server-1.19.99.904.tar.bz2
> SHA512: 
> b9dccc777d0a30c6b40bddffe1f359dde4103539c6598f04bf8cf5f59e6770229221a199c1866b4eba0cf8d2d87fe878985bbd2e3c6ec5b65e3f16195ea8d57e
>   xorg-server-1.19.99.904.tar.bz2
> PGP:  
> https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.904.tar.bz2.sig
> 
> https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.904.tar.gz
> MD5:  f5082147af9822ade469f808c420a121  xorg-server-1.19.99.904.tar.gz
> SHA1: c481217424beb1e0f0d38d98dfc4c194a1631354  xorg-server-1.19.99.904.tar.gz
> SHA256: f1fe5e27d0eab494a4eea11a075f8f6d3989c3683c22e0bdf5c060e57d351c0f  
> xorg-server-1.19.99.904.tar.gz
> SHA512: 
> dad39ecc6f8a99a74191d542709d03a14415f1065f8f2c8c68ad87d3fb7c3392eaf3ff97d90827f53d2c16e0e5acbaaa0f3bf580f60615c3f35b40965f23
>   xorg-server-1.19.99.904.tar.gz
> PGP:  
> https://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.19.99.904.tar.gz.sig
> 
> - ajax
> ___
> xorg-announce mailing list
> xorg-annou...@lists.x.org
> https://lists.x.org/mailman/listinfo/xorg-announce
___
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

[Olivier Fourdan]

Hi Adam,

On 10 April 2018 at 21:57, Adam Jackson  wrote:

> Another batch of cleanups and fixes, mostly in glamor and DRI3.
>
> At this point the only outstanding major feature for 1.20 that hasn't
> landed yet is EGLStreams support for Xwayland. The patches require some
> minor rebasing to account for per-window flips in Present, I'll post
> that momentarily I suppose. I'm honestly of two minds about merging it,
> the deafening silence of review feedback has not been encouraging.
>

FWIW, I actually looked at the patches and did not spot anything wrong at
the time, but I don't have any hardware/driver to actually try it, so I
cannot tell whether or not those are correct, so I did not reply...

What are the risks of landing it? It would break for hardware/driver which
are not supported yet anyway?

Cheers,
Olivier
___
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