The data type xcb_atom_t is an unsigned int (32 bit), but the optional
range argument is parsed with atoi(), which returns a signed int.
Even though it is possible to reach all values through clever casting,
it is more readable by properly using correct data types.
This also fixes a segmentation
If a low and high range limit has been specified, all atoms are
retrieved at once. This is also the reason why malloc() is used:
All cookies are stored before collecting the data.
By using chunks it is possible to specify a huge range or even
all possible atoms without running out of memory.
The manual page states that if no upper range limit has been specified,
no higher atoms will be printed. This is not true for
$ xlsatoms -range 0-
This prints the first 100 atoms, even though it already encountered an
invalid one at 0. The reason is that say_batch works as a batch, i.e.
The default format is %lu\t%s, not %ld\t%s, i.e. unsigned.
Signed-off-by: Tobias Stoeckmann
---
man/xlsatoms.man | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man/xlsatoms.man b/man/xlsatoms.man
index afa89bf..34d386e 100644
--- a/man/xlsatoms.man
+++ b/man/xlsatoms.man
@@
From: Ville Syrjälä
Add a new Xv port attribute XV_COLOR_RANGE to select the incoming YUV
quantization range. 0 means limited range (Y: 16-235, Cb/Cr: 16-240),
1 means full range (0-255).
We'll forward the quantization range information to the kernel via
the COLOR_RANGE kms property.
Cc:
From: Ville Syrjälä
Add a new Xv port attribute XV_COLOR_RANGE to select the incoming YUV
quantization range. 0 means limited range (Y: 16-235, Cb/Cr: 16-240),
1 means full range (0-255).
Cc: xorg-devel@lists.x.org
Signed-off-by: Ville Syrjälä
---
src/sna/sna_video_textured.c | 12
On Wed, Jul 04, 2018 at 09:59:18PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a new Xv port attribute XV_COLOR_RANGE to select the incoming YUV
> quantization range. 0 means limited range (Y: 16-235, Cb/Cr: 16-240),
> 1 means full range (0-255).
>
> Cc: xorg-devel@lists.x.org
>
