Re: Missing swapl() in Xext/saver.c?

2018-03-12 Thread Keith Packard
Alan Coopersmith writes: > On 03/10/18 01:31 AM, Mihai Moldovan wrote: >> int everywhere and includes the (ignored) B32 width specifier > > We could just delete those now, as they're just noise for the pre-processor > to strip ever since we dropped support for Cray builds with "everything is > a

Re: Missing swapl() in Xext/saver.c?

2018-03-12 Thread Alan Coopersmith
On 03/10/18 01:31 AM, Mihai Moldovan wrote: > int everywhere and includes the (ignored) B32 width specifier We could just delete those now, as they're just noise for the pre-processor to strip ever since we dropped support for Cray builds with "everything is a 64-bit int, using bitfields to emulat

Re: Missing swapl() in Xext/saver.c?

2018-03-12 Thread Keith Packard
Mihai Moldovan writes: > Sounds sane. Reverting to the initially intended BOOL type would cause > breakage, > but using CARD32 + swapl() would leave the struct size consistent and fix the > issue in newer versions. I've posted patches for xcb/proto, xorgproto and the X server. For the X server,

Re: [PATCH xorgproto] screensaver: Fix encoding of ScreenSaverSuspend 'suspend' element

2018-03-12 Thread Keith Packard
Keith Packard writes: > Was using Bool, which is not a defined X protocol encoding type and > has presumably been a 32-bit type. Switch to a CARD32 to be compatible > while at least being well defined. I found where Bool was probably coming from -- Xdefs.h, which defines Bool as 'int'. -- -kei

[PATCH xserver] Xext/saver: Swap ScreenSaverSuspend 'suspend' field. Handle old XCB clients.

2018-03-12 Thread Keith Packard
This field was defined as a Bool in the protocol headers and BOOL in xcb. Bool is not a valid type for protocol fields. It is defined as 'int' by Xdefs.h, which we expect to be 32-bits on all machines. The protocol headers and xcb have patches posted to switch to CARD32, which is at least well def

[PATCH xcb/proto] screensaver: Use CARD32 encoding for ScreenSaverSuspend 'suspend'

2018-03-12 Thread Keith Packard
This was set to BOOL, but the protocol headers used Bool, presumably a 32-bit type. We're switching everything to CARD32 as the best option for compatibility. Signed-off-by: Keith Packard --- src/screensaver.xml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/screensave

[PATCH xorgproto] screensaver: Fix encoding of ScreenSaverSuspend 'suspend' element

2018-03-12 Thread Keith Packard
Was using Bool, which is not a defined X protocol encoding type and has presumably been a 32-bit type. Switch to a CARD32 to be compatible while at least being well defined. Signed-off-by: Keith Packard --- include/X11/extensions/saverproto.h | 2 +- scrnsaverproto.pc.in| 2 +- 2

Re: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

2018-03-12 Thread Daniel Stone
On 12 March 2018 at 16:57, Mario Kleiner wrote: > The check for "no modifier specified" in drmmode_is_format_supported() > should check for DRM_FORMAT_MOD_INVALID, not for zero, as zero actually > means DRM_FORMAT_MOD_LINEAR. If I had a time machine, that would probably be the first thing I would

[PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

2018-03-12 Thread Mario Kleiner
The check for "no modifier specified" in drmmode_is_format_supported() should check for DRM_FORMAT_MOD_INVALID, not for zero, as zero actually means DRM_FORMAT_MOD_LINEAR. This allows page-flipping again when appropriate, as tested under nouveau and ati drivers. Fixes: 9d147305b404 ("modesetting:

[PATCH xserver] Xext/shm: Downgrade from error to debug log output about success

2018-03-12 Thread Alexander Volkov
Signed-off-by: Alexander Volkov --- Xext/shm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Xext/shm.c b/Xext/shm.c index 15e1b67ff..fc8441c43 100644 --- a/Xext/shm.c +++ b/Xext/shm.c @@ -1199,7 +1199,7 @@ shm_tmpfile(void) #ifdef O_TMPFILE fd = open(SHMDIR, O_TMPF

Re: [PATCH v3 app/xrandr] Document that --dpi and --fbmm options set DPI of whole X screen

2018-03-12 Thread Giuseppe Bilotta
On Sat, Mar 10, 2018 at 4:23 PM, Pali Rohár wrote: > Explicitly document and make it clear that those options do not change > DPI of some monitor output. Also state that these options have no useful > meaning for multi-monitor configuration. > > Signed-off-by: Pali Rohár FWIW, Reviewed-by: Gius