Re: XInput2 raw events only for root window

[Peter Hutterer]

On Fri, May 29, 2020 at 12:25:42AM -0500, Will Song wrote:
> Hey all. I am writing a small-ish application and when grabbing for keyboard
> events I noticed that it was not possible to select for raw key press/releasee
> events on the client window I created, and must be done on the screen root. Is
> this an intentional design in the xorg server or is it possible to do this
> generally in a non-root window? Thanks.

It's an intentional design, from the XI2proto.txt spec documents:
RawEvents are sent exclusively to all root windows.

Raw events don't have any meaning otherwise since they're, well, raw events
from the device and the device doesn't know anything about windows, focus,
etc.

Cheers,
   Peter
___
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: AW: Implementing PseudoColor support on TrueColor screens

[The Rasterman]

On Tue, 2 Jun 2020 10:06:01 + Walter Harms  said:

> the correct way to do is use XPutPixel().

Unfortunately it's also the very slow way. The right way is to handle the pixel
data pointer yourself correctly given format (8, 16, 32bit) and x visual rgb
masks and use the bytes_per_line correctly. This is your fast path for all
the common cases. Also try implement them in SIMD (MMX/SSE/Nneon/SVE/Altivec
etc.). If it's not an optimized common path, then fall back to XPutPixel.

You probably want to have the palette lookup table specifically filled and
optimized for the pixel format "ahead of time" so it's already 1:1 correct for
the right xRGB pixel value to expand to so all you need is a dumb lookup,
so the expand code is something like:

// assume the following input:
//unsigned char *srcpixel; // is input pointer top-left to bottom right
//int w, h; // size of image in pixels (width and height)
//unsigned int palette_lookup[256]; // expanded index -> xRGB 32bit layout
//  // you could do the same for 16bpp too
unsigned char *pixelrow;
unsigned int *pixel;

pixelrow = (unsigned char *)ximage->data;
// work from top left to bottom-right row by row
for (y = 0; y < h; y++) {
  pixelrow += ximage->bytes_per_line;
  pixel = (unsigned int *)pixelrow;
  for (x = 0; x < w; x++) {
pixel = palette_lookup[*srcpixel];
pixel++;
srcpixel++;
  }
}

Even better if you can throw some SIMD in (I'd need to think about it a bit,
so not going to do it in an e-mail) and then write out 2 or 4 pixels at a time
(you then jump by 4 pixels at a time, instead of 1, dealing with
non-multiple-of-2-or-4 sizes as a special end-of-row cleanup at the end of a
row).

Also you really should use XShmPutImage - it's drastically faster than basic
XImage (but only for local xservers, so you have to query for it and test you
can XShmAttach() - will not work across a network). Also keep in mind that you
can have several XShmPutImages in flight as it's async, so look for the xshm
completion event to know when to clean up or be able to recycle your shm
segment - just keep a pool of xshm images/sysv shm segments around and as puts
complete put them back in the spare pool and when you need a new shm image for
a new frame, look in your pool for an available image, or create it if needed
then). You could also be lazy and use XSync()... :) it comes with blocking as a
side-effect.

> color these days if pretty easy  color=0/r/g/b
> 
> You need a lookuptable for 256 colors (=st2d_8to24table[i] ?)
> and that should it be.
> 
> re,
>  wh
> 
> 
> Von: xorg  im Auftrag von Sleep
>  Gesendet: Dienstag, 2. Juni 2020 08:28:13
> An: xorg@lists.x.org
> Betreff: Implementing PseudoColor support on TrueColor screens
> 
> Is there any documentation, article or book on how to convert the colors
> displayed by a program that was originally written to work on 8 bit
> screens? The problem I am facing seems to be related to how pixels are
> represented in the 'data' member of the XImage structure, which results
> in a squashed image and colors being displayed incorrectly. The only
> reference I have are two functions in the Quake source code:
> xlib_rgb24()[1] and st3_fixup()[2], which are used to convert the colors
> (but I cannot comprehend them because the format is unknown to me), but
> I found nothing that could make the image fill the window[3] properly. I
> could use SDL to easily get around this issue but I specifically want to
> use Xlib.
> 
> I appreciate any help to learn.
> 
> [1]
> 
> [2]
> 
> [3] https://postimg.cc/MfRz0Dk7
> [4] https://i.postimg.cc/brVdhC3B/doom.png
> ___
> 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
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
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: AW: AW: Implementing PseudoColor support on TrueColor screens

[Sleep]

This should be slightly easier to read:

Display*X_display = NULL;
Window  X_mainWindow;
ColormapX_cmap;
Visual* X_visual;
GC  X_gc;
int X_screen;
XVisualInfo X_visualinfo;
XImage* image = NULL;
int X_width;
int X_height;

unsigned long st2d_8to24table[256];
int32_t  shiftmask_fl = 0;
int32_t  r_shift, g_shift, b_shift;
uint32_t r_mask, g_mask, b_mask;

//
// I_InitGraphics
//
// Creates and maps window
void I_InitGraphics (void)
{
char* displayname = NULL;

X_width = SCREENWIDTH;
X_height = SCREENHEIGHT;

// open the display
X_display = XOpenDisplay(displayname);

// use the default visual
X_screen = DefaultScreen(X_display);
XMatchVisualInfo(X_display, X_screen, 24, TrueColor, _visualinfo);
X_visual = X_visualinfo.visual;

// create the main window
X_mainWindow = XCreateWindow(X_display,
 RootWindow(X_display, X_screen),
 0, 0,
 X_width, X_height,
 0, // borderwidth
 X_visualinfo.depth, // depth
 InputOutput,
 X_visual,
 0,
 0);

// create the GC
X_gc = XCreateGC(X_display,
 X_mainWindow,
 0,
 NULL);

// map the window
XMapWindow(X_display, X_mainWindow);

image = XCreateImage(X_display,
 X_visual,
 X_visualinfo.depth,
 ZPixmap,
 0,
 malloc((X_width * 4) * X_height),
 X_width, X_height,
 32,
 0);

screens[0] = (byte *)image->data;
}

// Convert colors to 24 bits, called by I_FinishUpdate()
void st3_fixup (int width, int height)
{
uint8_t *row_src;

for (int y = 0; y < height; y++) {
row_src = (uint8_t *)>data [y * image->bytes_per_line];
for (int x = width-1; x >= 0; x--) {
XPutPixel(image, x, y, st2d_8to24table[row_src[x]]);
}
}
}

// Called by xlib_rgb24()
void shiftmask_init (void)
{
unsigned int x;

r_mask = X_visual->red_mask;
g_mask = X_visual->green_mask;
b_mask = X_visual->blue_mask;

for (r_shift = -8, x = 1; x < r_mask; x = x << 1)
r_shift++;

for (g_shift = -8, x = 1; x < g_mask; x = x << 1)
g_shift++;

for (b_shift = -8, x = 1; x < b_mask; x = x << 1)
b_shift++;

shiftmask_fl = 1;
}

// Called by UploadNewPalette()
unsigned long xlib_rgb24 (int r, int g, int b)
{
unsigned long p;

if (shiftmask_fl == 0)
shiftmask_init();

p = 0;

if (r_shift > 0) {
p = (r << (r_shift)) & r_mask;
} else if (r_shift < 0) {
p = (r >> (-r_shift)) & r_mask;
} else p |= (r & r_mask);

if (g_shift > 0) {
p |= (g << (g_shift)) & g_mask;
} else if (g_shift < 0) {
p |= (g >> (-g_shift)) & g_mask;
} else p |= (g & g_mask);

if (b_shift > 0) {
p |= (b << (b_shift)) & b_mask;
} else if (b_shift < 0) {
p |=(b >> (-b_shift)) & b_mask;
} else p |= (b & b_mask);

return p;
}

//
// Palette stuff.
//
void UploadNewPalette (Colormap cmap, byte *palette)
{
(void)cmap; // UNUSED
for (int i = 0; i < 256; i++)
{
st2d_8to24table[i] = xlib_rgb24(palette[i * 3], palette[i * 3 + 
1],palette[i * 3 + 2]);

}
}

//
// I_SetPalette
//
void I_SetPalette (byte* palette)
{
UploadNewPalette(X_cmap, palette);
}

//
// I_FinishUpdate
//
// Display the image on the window
void I_FinishUpdate (void)
{
// Convert colors of the image to 24 bits color depth
st3_fixup(X_width, X_height);

// draw the image
XPutImage(X_display,
  X_mainWindow,
  X_gc,
  image,
  0, 0,
  0, 0,
  X_width, X_height );

// sync up with server
XSync(X_display, False);
}

___
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: X11 server that supports OpenGL 1.5 or higher

[Nathan Kidd]

On 2020-05-23 12:28 p.m., Joe Hays wrote:
> I cannot find an X11 server for Windows that supports OpenGL 1.5 or
> greater. Xming doesn't, VcXsrv doesn't, Cygwin doesn't, Xmanage doesn't...
> 
> Obviously a free solution is preferred but I'll consider commercial if
> it's the only option...
> 
> Anyone know of a solution?

Are you sure you don't want VirtualGL instead?

There is no official GLX protocol for OpenGL 1.5+. NVIDIA implemented
unofficial protocol with their AllowUnofficialGLXProtocol /
__GL_ALLOW_UNOFFICIAL_PROTOCOL settings.  I think it allows up to the
OpenGL 2.x range but I haven't looked in detail.

There was a company out of the UK that supported this protocol in their
server, IIRC, but I forget their name.

Mostly people don't care about that support because by the time you're
using those features your app likely cannot stand the performance hit
from indirect rendering, so a form of server-side rendering is used
instead.  See VirtualGL.

HTH,

-Nathan
___
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: AW: AW: Implementing PseudoColor support on TrueColor screens

[Sleep]

No, that is not intentional, the original function had x = width-1 and I 
forgot to change that for clarity, and yes, the colors are converted 
perfectly, by "squashed" I mean what is happening in this image (that is 
Doom).

https://postimg.cc/MfRz0Dk7
You see, only 1/4 of the window is being filled, instead of drawing on 
the entire window; I just thought the problem was in that function but 
that seems to be a problem unrelated to the colors. Here is the (super 
messy) original code: 
https://github.com/so-sleepy/DOOM/blob/bb4382c111ff0a83e52dd7e043884bf41c89daa0/linuxdoom-1.10/i_video.c#L769


I_InitGraphics() creates the window, I_FinishUpdate() draws the image on 
the window (you can ignore all if statements with 'multiply' inside, 
those are used to scale), UploadNewPalette() takes the game's palette 
and use that to build the lookup table.


> To make things more easy to debug, can you save image->data
> where you know what who that should look like ? then you can play
> with a simple display code instead of that.

Thank you, I will do exactly that! I will try my best to narrow down the 
issue.

___
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

AW: AW: Implementing PseudoColor support on TrueColor screens

[Walter Harms]

a assume this is intentional backwards ?
for (int x = width-1; x >= 0; x--) {

if st2d_8to24table contains no rubbish the colors should be ok now, are they ?

what means "squashed image" ? a scaling problem ?

To make things more easy to debug, can you save image->data
where you know what who that should look like ? then you can play
with a simple display code instead of that.

re,
 wh

Von: xorg  im Auftrag von Sleep 

Gesendet: Dienstag, 2. Juni 2020 16:09:20
An: xorg@lists.x.org
Betreff: Re: AW: Implementing PseudoColor support on TrueColor screens

Thank you very much, Walter. st3_fixup() (adapted for my use) is a lot
more readable now:

void st3_fixup(XImage *image, int width, int height)
{
 uint8_t *row_src;

 for (int y = 0; y < height; y++) {
 row_src = (uint8_t *)>data [y * image->bytes_per_line];
 for (int x = width-1; x >= 0; x--) {
 XPutPixel(image, x, y, st2d_8to24table[row_src[x]]);
 }
 }
}

The issue I am having persists, just letting you know that you have
helped me on something, again, thank you a lot.
___
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: AW: Implementing PseudoColor support on TrueColor screens

[Sleep]

Thank you very much, Walter. st3_fixup() (adapted for my use) is a lot 
more readable now:


void st3_fixup(XImage *image, int width, int height)
{
uint8_t *row_src;

for (int y = 0; y < height; y++) {
row_src = (uint8_t *)>data [y * image->bytes_per_line];
for (int x = width-1; x >= 0; x--) {
XPutPixel(image, x, y, st2d_8to24table[row_src[x]]);
}
}
}

The issue I am having persists, just letting you know that you have 
helped me on something, again, thank you a lot.

___
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

AW: Implementing PseudoColor support on TrueColor screens

[Walter Harms]

the correct way to do is use XPutPixel().
color these days if pretty easy  color=0/r/g/b

You need a lookuptable for 256 colors (=st2d_8to24table[i] ?)
and that should it be.

re,
 wh


Von: xorg  im Auftrag von Sleep 

Gesendet: Dienstag, 2. Juni 2020 08:28:13
An: xorg@lists.x.org
Betreff: Implementing PseudoColor support on TrueColor screens

Is there any documentation, article or book on how to convert the colors
displayed by a program that was originally written to work on 8 bit
screens? The problem I am facing seems to be related to how pixels are
represented in the 'data' member of the XImage structure, which results
in a squashed image and colors being displayed incorrectly. The only
reference I have are two functions in the Quake source code:
xlib_rgb24()[1] and st3_fixup()[2], which are used to convert the colors
(but I cannot comprehend them because the format is unknown to me), but
I found nothing that could make the image fill the window[3] properly. I
could use SDL to easily get around this issue but I specifically want to
use Xlib.

I appreciate any help to learn.

[1]

[2]

[3] https://postimg.cc/MfRz0Dk7
[4] https://i.postimg.cc/brVdhC3B/doom.png
___
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

Implementing PseudoColor support on TrueColor screens

[Sleep]

Is there any documentation, article or book on how to convert the colors 
displayed by a program that was originally written to work on 8 bit 
screens? The problem I am facing seems to be related to how pixels are 
represented in the 'data' member of the XImage structure, which results 
in a squashed image and colors being displayed incorrectly. The only 
reference I have are two functions in the Quake source code: 
xlib_rgb24()[1] and st3_fixup()[2], which are used to convert the colors 
(but I cannot comprehend them because the format is unknown to me), but 
I found nothing that could make the image fill the window[3] properly. I 
could use SDL to easily get around this issue but I specifically want to 
use Xlib.


I appreciate any help to learn.

[1] 

[2] 


[3] https://postimg.cc/MfRz0Dk7
[4] https://i.postimg.cc/brVdhC3B/doom.png
___
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