[PATCH xserver 1/2] config: wait for DRM device to be successful initiated
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
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
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
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
I'm wondering if it's this commit that added it back in January commit 7617a0a180a2cd3427a8ffa9534152df6a8fecbf Author: Qiang YuDate: 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
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 Lothianwrote: > 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
The journal.freeze I mentioned but was too big to attach On 11 April 2018 at 22:53, Mike Lothianwrote: > 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
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
On Wed, Apr 11, 2018 at 2:44 AM, Thomas Klausnerwrote: > 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
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
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
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 KlausnerSigned-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
From: Emil VelikovReplace 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
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übkingwrote: > 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
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
Hey Adam, On Wed, Apr 11, 2018 at 4:40 PM, Adam Jacksonwrote: > 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
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
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
Hi Adam, [Re-sending to xorg-devel where this was intended, sorry!] On 10 April 2018 at 21:57, Adam Jacksonwrote: > 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
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
Hi Adam, On 10 April 2018 at 21:57, Adam Jacksonwrote: > 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