All the Xlib documentation seems to imply that threads can be used , however if I attempt to put XNextEvent() or XPending() in a thread , the rsult is a GP fault . The error message suggests using XInitThreads() but it still generates a GP fault.

Tried using XlockDisplay() and XUnlockDisplay() in the thread but still get a GP fault.

X Error of failed request: BadLength (poly request too large or internal Xlib length error)
Major opcode of failed request: 100 (X_ChangeKeyboardMapping) Serial number of failed request: 20
Current serial number in output stream: 35

X11 code which causes the problem in the thread :

   NewEvent := Xpending(TheDisplay) > 0 ;
   if NewEvent then
     begin
      XNextEvent(TheDisplay, @myevent);
       KeypressedX :=  myevent._type = keypress ;
     end;

Any suggestions are welcomed. Thanks in advance.

SOLVED

XInitThreads() must be called prior to initailizing X , then it works using XLockDisplay() and XUnlockDisplay()

XLockDisplay(TheDisplay);
NewEvent := Xpending(TheDisplay) > 0 ;
   if NewEvent then
     begin
      XNextEvent(TheDisplay, @myevent);
       KeypressedX :=  myevent._type = keypress ;
     end;
XUnLockDisplay(TheDisplay);

Interesting. I suppose that could lead us back to which widgetsets support full multithreading.

Mark Morgan Lloyd wrote

Interesting. I suppose that could lead us back to which widgetsets support full multithreading.

And it just surprises me what features Xlib / X11 has - yet everybody seems so eager to replace it with something else (often with something less feature rich, yet tick the "cool" box). Sure X11 could do with some modernization, but I still think it is damn impressive - considering how long ago it was created. Software engineers from that time-frame were pretty impressive.

Regards,
- Graeme -

The principal problems seem to be related to the number of apps which demand a high-bandwidth link to the video, with even web browsers (as distinct from embedded video content) now expecting OpenGL.

long ago it was created. Software engineers from that time-frame were pretty impressive.

Not software engineers in the general case, but MIT engineers and the Boston/Cambridge culture (with a nod to Bell Labs in New Jersey).

In our previous episode, Graeme Geldenhuys said:

(If you attend Fosdem occasionally, I often find lectures when I have no other lecture to go to. Keith Packard also often has lectures there)

Yes , Xlib has many impressive features , but it is lacking in a simple (and fast) way to independently write to specific bit planes without altering the other bit planes for 2D animation. OpenGL can be used (I think) for 2D automation using the z-buffer , but it really is and end around to a deficiency in Xlib.

Marco van de Voort wrote

(If you attend Fosdem occasionally, I often find lectures

Umm, I'll have to make a plan.

when I have no other lecture to go to. Keith Packard also often has lectures there)

I have read so many of Keith's published papers. They are always good and very interesting.

Regards,
- Graeme -

An interesting discussion at this link on the subject.

http://networkedblogs.com/axUUw

*Effectively, the beginning of the main() function is the only really safe place to call XInitThreads(). *

Graeme Geldenhuys wrote

And it just surprises me what features Xlib / X11 has

X11 originally has been designed to work in a client-server way via TCP-IP. Using a hardware "X-Terminal" and a Unix box without any graphical hardware. :-)

If in Lazarus, it would be possible to switch to native X11support (via "CustomDrawn" or via the LCL-variant of "fpGUI") by just switching the "LCL Widget Type" project option (IMHO sadly now deeply hidden in "Additions and Overrides") appropriately and a - say - "GTK" project would simply work as expected after the switch, there would be a great way to create a small executable for embedded use with a remote GUI.

OTOH the "wrong" client<->server layout of X11 makes "attaching" from a remote site to such a (already running) project not as easy as it should. Here "NX" instead of X11 would be a more convenient choice (no idea how this could be accomplished).

The most convenient "GUI remoteing" choice would be decent support for a browser based "Web-GUI" (similar to the - now seemingly dead - "ExtPascal" approach), that emulates the LCL widgets via Java script code. Here we could have as well embedded devices (with built-in web server similar to "fp-web") or "CGI" programs behind a web server (via FCGI or ISAPI) (also similar to "fp-web").

As "CustomDrawn" is more mature, and "WebSockets" (for spontaneous Host->Browser events) is supported by all Browsers, right now, I suppose a rather small set of basic JavaScript generated Widgets might suffice to allow for a rather decent emulation of a real LCL based GUI to be shown in a Browser. Based on "CustomDrawn" and "fp-web", the appropriate "LCL Widget Type" seems to be doable.

-Michael